Acceptance annex
See what each requirement means, where it came from and how it will be checked. These planned cases do not record client approval or operational test success. Send comments and approval evidence through Institution review.
Retained review baseline: 190 requirements, 150 Design shown and 40 Technical only. Technical controls are future service requirements. The 820 decisions remain candidate examples.
Search applies to the records below.
Coverage and acceptance workbook · Requirement matrix · Clauses · Cases · NFR conditions · Release options
Requirements and provenance
Owners are proposed until the institution appoints them. A broad contractual capability does not establish acceptance of every detailed feature.
FR029 · Describe each source and dataset
SHARED must keep source ownership, custody, licence, update frequency, coverage, quality, classification, dataset versions and available distributions in the shared catalogue.
Source class: Documented consultation input
Evidence locator: SRS Version 1.5, FR029, body after heading at paragraph 410
Source passage: SHARED must keep source ownership, custody, licence, update frequency, coverage, quality, classification, dataset versions and available distributions in the shared catalogue.
Need: Proposed need: Describe each source and dataset. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR030 · Describe versioned fields
SHARED must expose each dataset version's field definitions, types, units and supported integration method.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR030, body after heading at paragraph 413
Source passage: SHARED must expose each dataset version's field definitions, types, units and supported integration method.
Need: Proposed need: Describe versioned fields. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR031 · Define indicators before results
SHARED must record each indicator definition's unit, owner, frequency, disaggregation, baseline and target descriptive information, and required sources. Observations require approved contracts.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR031, body after heading at paragraph 416
Source passage: SHARED must record each indicator definition's unit, owner, frequency, disaggregation, baseline and target descriptive information, and required sources. Observations require approved contracts.
Need: Proposed need: Define indicators before results. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR032 · Separate original input from curated data
SHARED must keep unchanged or versioned staged input, then use the approved defined data structures for accepted records. Do not create a single store of values without defined types and meanings.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR032, body after heading at paragraph 419
Source passage: SHARED must keep unchanged or versioned staged input, then use the approved defined data structures for accepted records. Do not create a single store of values without defined types and meanings.
Need: Proposed need: Separate original input from curated data. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR033 · Follow up with the provider
SHARED must use shared assigned work, responses, evidence and review for dataset requests and quality feedback. Show permitted usage relationships without claiming complete view/download telemetry.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR033, body after heading at paragraph 422
Source passage: SHARED must use shared assigned work, responses, evidence and review for dataset requests and quality feedback. Show permitted usage relationships without claiming complete view/download telemetry.
Need: Proposed need: Follow up with the provider. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR034 · Connect usable fields to sources
SHARED must retain reviewed links from domain fields to dataset fields that identify the shared field and version, permitted area and period, and actual source availability. A field link must not copy values or approve observations.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR034, body after heading at paragraph 425
Source passage: SHARED must retain reviewed links from domain fields to dataset fields that identify the shared field and version, permitted area and period, and actual source availability. A field link must not copy values or approve observations.
Need: Proposed need: Connect usable fields to sources. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR035 · Use controlled entry routes
SHARED must require external contributors to use authenticated web, mobile or API workflows. They must not read or write database tables directly.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR035, body after heading at paragraph 428
Source passage: SHARED must require external contributors to use authenticated web, mobile or API workflows. They must not read or write database tables directly.
Need: Proposed need: Use controlled entry routes. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR036 · Follow configured transitions
SHARED must enforce the configured workflow for draft, submission, validation, review, return, approval, publication and archive steps. Invalid transitions must fail atomically.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR036, body after heading at paragraph 431
Source passage: SHARED must enforce the configured workflow for draft, submission, validation, review, return, approval, publication and archive steps. Invalid transitions must fail atomically.
Need: Proposed need: Follow configured transitions. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR037 · Keep submission context
SHARED must retain source, submitter, organization, time, reporting period, schema version, rights, owner, sensitivity and validation outcomes as unchanged or versioned evidence.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR037, body after heading at paragraph 434
Source passage: SHARED must retain source, submitter, organization, time, reporting period, schema version, rights, owner, sensitivity and validation outcomes as unchanged or versioned evidence.
Need: Proposed need: Keep submission context. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR038 · Keep manual source details
SHARED must store the supplied source resources, source rows and measured location accuracy with the shared observation. Reject unsupported precision, overflow and excessive text instead of silently changing it.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR038, body after heading at paragraph 437
Source passage: SHARED must store the supplied source resources, source rows and measured location accuracy with the shared observation. Reject unsupported precision, overflow and excessive text instead of silently changing it.
Need: Proposed need: Keep manual source details. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR039 · Keep missing values distinct
SHARED must use configured field types and checks. Missing values, zero and false must remain different. Unknown observation time and GN must not be guessed.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR039, body after heading at paragraph 440
Source passage: SHARED must use configured field types and checks. Missing values, zero and false must remain different. Unknown observation time and GN must not be guessed.
Need: Proposed need: Keep missing values distinct. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR040 · Reuse detailed field forms
SHARED must reuse published forms for surveys, trials, training and field feedback. When a form value is used in a report field, keep the approved mapping and the link back to the submitted evidence.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR040, body after heading at paragraph 443
Source passage: SHARED must reuse published forms for surveys, trials, training and field feedback. When a form value is used in a report field, keep the approved mapping and the link back to the submitted evidence.
Need: Proposed need: Reuse detailed field forms. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR041 · Validate a batch before confirmation
SHARED must process every structured dataset import, including project and deliverable onboarding, through a published CSV, Excel, JSON or restricted XML contract, a quarantined original, row validation and a preview.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR041, body after heading at paragraph 446
Source passage: SHARED must process every structured dataset import, including project and deliverable onboarding, through a published CSV, Excel, JSON or restricted XML contract, a quarantined original, row validation and a preview.
Need: Proposed need: Validate a batch before confirmation. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR042 · Approve and save the batch safely
SHARED must bind independent import approval to the exact list of included rows and target schema.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR042, body after heading at paragraph 449
Source passage: SHARED must bind independent import approval to the exact list of included rows and target schema.
Need: Proposed need: Approve and save the batch safely. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR043 · Keep the import history
SHARED must retain auditable batches, rows, validation decisions, source evidence and corrective follow-up, protected by their access scope.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR043, body after heading at paragraph 452
Source passage: SHARED must retain auditable batches, rows, validation decisions, source evidence and corrective follow-up, protected by their access scope.
Need: Proposed need: Keep the import history. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR044 · Recover repeated upload results safely
SHARED must keep the same identifier when an upload or command is retried. If the response is lost, retain the protected original and check the saved outcome before trying again. Never change the earlier evidence to make the retry appear successful.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR044, body after heading at paragraph 455
Source passage: SHARED must keep the same identifier when an upload or command is retried. If the response is lost, retain the protected original and check the saved outcome before trying again. Never change the earlier evidence to make the retry appear successful.
Need: Proposed need: Recover repeated upload results safely. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR045 · Provide one common file parser
SHARED must support CSV, XLSX, JSON arrays of scalar-valued records and restricted XML row documents through one versioned mapping and validation workflow. Reject unsupported nesting and oversized content. Never execute spreadsheet formulas, macros, XML DTDs or external entities.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR045, body after heading at paragraph 458
Source passage: SHARED must support CSV, XLSX, JSON arrays of scalar-valued records and restricted XML row documents through one versioned mapping and validation workflow. Reject unsupported nesting and oversized content. Never execute spreadsheet formulas, macros, XML DTDs or external entities.
Need: Proposed need: Provide one common file parser. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR046 · Register the original purpose
SHARED must record original checksum, owner, classification and source purpose. Reuse matching sources only within compatible scope; requirements or guidance must not become observations automatically.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR046, body after heading at paragraph 461
Source passage: SHARED must record original checksum, owner, classification and source purpose. Reuse matching sources only within compatible scope; requirements or guidance must not become observations automatically.
Need: Proposed need: Register the original purpose. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR047 · Gate real AI processing
SHARED must require approved provider configuration, processing permission and genuine clean scanning before document processing. Missing setup must be visible; never invent a scan or extraction result.
Source class: Externally conditional option
Evidence locator: SRS Version 1.5, FR047, body after heading at paragraph 464
Source passage: SHARED must require approved provider configuration, processing permission and genuine clean scanning before document processing. Missing setup must be visible; never invent a scan or extraction result.
Need: Proposed need: Gate real AI processing. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04; C05; C06; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR048 · Keep extraction evidence
SHARED must retain the original passage, table or page, uncertainty and processing record with each extraction suggestion. Values must use allowed shared data types and destinations.
Source class: Externally conditional option
Evidence locator: SRS Version 1.5, FR048, body after heading at paragraph 467
Source passage: SHARED must retain the original passage, table or page, uncertainty and processing record with each extraction suggestion. Values must use allowed shared data types and destinations.
Need: Proposed need: Keep extraction evidence. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04; C05; C06; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR049 · Review several domains from one document
SHARED must require permitted users to verify every proposed base domain, subject, attribute and value. Route approved mappings through the relevant shared dataset batches and independent reviews.
Source class: Externally conditional option
Evidence locator: SRS Version 1.5, FR049, body after heading at paragraph 470
Source passage: SHARED must require permitted users to verify every proposed base domain, subject, attribute and value. Route approved mappings through the relevant shared dataset batches and independent reviews.
Need: Proposed need: Review several domains from one document. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04; C05; C06; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR050 · Keep mapping approval separate from acceptance
SHARED must record the mapping decision separately from the review of extracted values. Keep rejected suggestions and corrections. Before saving, check permission and the current destination version again.
Source class: Externally conditional option
Evidence locator: SRS Version 1.5, FR050, body after heading at paragraph 473
Source passage: SHARED must record the mapping decision separately from the review of extracted values. Keep rejected suggestions and corrections. Before saving, check permission and the current destination version again.
Need: Proposed need: Keep mapping approval separate from acceptance. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04; C05; C06; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR051 · Register a controlled source feed
SHARED must bind each feed's source and dataset version to approved fields, keys, units, location context and origin designation. Disabled feeds cannot acquire or ingest new events. Configuration changes preserve history and invalidate affected approvals.
Source class: Externally conditional option
Evidence locator: SRS Version 1.5, FR051, body after heading at paragraph 476
Source passage: SHARED must bind each feed's source and dataset version to approved fields, keys, units, location context and origin designation. Disabled feeds cannot acquire or ingest new events. Configuration changes preserve history and invalidate affected approvals.
Need: Proposed need: Register a controlled source feed. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04; C06; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR052 · Review provider mappings
SHARED must record source-event, observation-time, applicable device and value-field mappings for provider messages. An independent reviewer approves them; a mapping or governing-field change invalidates approval.
Source class: Externally conditional option
Evidence locator: SRS Version 1.5, FR052, body after heading at paragraph 479
Source passage: SHARED must record source-event, observation-time, applicable device and value-field mappings for provider messages. An independent reviewer approves them; a mapping or governing-field change invalidates approval.
Need: Proposed need: Review provider mappings. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04; C06; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR053 · Decode supported provider formats
SHARED must provide adapters for institutional data services and device gateways using approved message contracts. An unsupported source or message format requires an accepted adapter contract before connection.
Source class: Externally conditional option
Evidence locator: SRS Version 1.5, FR053, body after heading at paragraph 482
Source passage: SHARED must provide adapters for institutional data services and device gateways using approved message contracts. An unsupported source or message format requires an accepted adapter contract before connection.
Need: Proposed need: Decode supported provider formats. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04; C06; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR054 · Keep honest row outcomes
SHARED must retain the source message identity, observed and received times, mapping version, staged-pending rows and rejected-row reasons in each intake receipt.
Source class: Externally conditional option
Evidence locator: SRS Version 1.5, FR054, body after heading at paragraph 485
Source passage: SHARED must retain the source message identity, observed and received times, mapping version, staged-pending rows and rejected-row reasons in each intake receipt.
Need: Proposed need: Keep honest row outcomes. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04; C06; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR055 · Prevent repeated source events
SHARED must reuse unchanged source events and require an explicit correction for changed content. Keep out-of-order arrival distinct from revision. Retained archive batches must use their documented all-or-none saving and duplicate checks.
Source class: Externally conditional option
Evidence locator: SRS Version 1.5, FR055, body after heading at paragraph 488
Source passage: SHARED must reuse unchanged source events and require an explicit correction for changed content. Keep out-of-order arrival distinct from revision. Retained archive batches must use their documented all-or-none saving and duplicate checks.
Need: Proposed need: Prevent repeated source events. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04; C06; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR056 · Keep live activation explicit
SHARED must keep connections inactive until a real endpoint, protected machine identity, rights and mapping review have been supplied.
Source class: Externally conditional option
Evidence locator: SRS Version 1.5, FR056, body after heading at paragraph 491
Source passage: SHARED must keep connections inactive until a real endpoint, protected machine identity, rights and mapping review have been supplied.
Need: Proposed need: Keep live activation explicit. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04; C06; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR057 · Track quality issues and corrections
SHARED must retain versions, reasons, source references and permitted history for quality issues and observation corrections.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR057, body after heading at paragraph 494
Source passage: SHARED must retain versions, reasons, source references and permitted history for quality issues and observation corrections.
Need: Proposed need: Track quality issues and corrections. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR058 · Apply published field rules
SHARED must use the same published checks for numeric values, text, required dates and source identifiers on every entry route. Changing a rule already used by records requires a reviewed new version.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR058, body after heading at paragraph 497
Source passage: SHARED must use the same published checks for numeric values, text, required dates and source identifiers on every entry route. Changing a rule already used by records requires a reviewed new version.
Need: Proposed need: Apply published field rules. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR059 · Review candidate identity links
SHARED must prevent candidate identity suggestions from approving themselves. Link source keys to a permitted registered object only through the reviewed workflow, preserving source-specific scope.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR059, body after heading at paragraph 500
Source passage: SHARED must prevent candidate identity suggestions from approving themselves. Link source keys to a permitted registered object only through the reviewed workflow, preserving source-specific scope.
Need: Proposed need: Review candidate identity links. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR060 · Keep differing values from each source
SHARED must retain both originals and their units, places, dates, methods, review and origin when comparing source-reported values. Do not silently average or overwrite conflicting claims.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR060, body after heading at paragraph 503
Source passage: SHARED must retain both originals and their units, places, dates, methods, review and origin when comparing source-reported values. Do not silently average or overwrite conflicting claims.
Need: Proposed need: Keep differing values from each source. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR061 · Limit preferred source decisions
When a reviewer chooses a source, record the purpose and evidence for that choice. Check that units, place, period, field mapping and review are suitable. Recheck the choice after a source changes.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR061, body after heading at paragraph 506
Source passage: When a reviewer chooses a source, record the purpose and evidence for that choice. Check that units, place, period, field mapping and review are suitable. Recheck the choice after a source changes.
Need: Proposed need: Limit preferred source decisions. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR062 · Reuse the quality worklist
Provide one worklist for reviewing values, correcting errors and comparing sources. Keep versions of field and related-field rules. Experts must approve scientific plausibility checks, calibration and specialist rules before those checks are used.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR062, body after heading at paragraph 509
Source passage: Provide one worklist for reviewing values, correcting errors and comparing sources. Keep versions of field and related-field rules. Experts must approve scientific plausibility checks, calibration and specialist rules before those checks are used.
Need: Proposed need: Reuse the quality worklist. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed provider/data owner, steward and receiving institutional reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR001 · Maintain organizations and people
SHARED must allow authorized administrators to maintain organizations, units, stakeholders and contacts. They must keep these records separate from login accounts and retain deactivation history.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR001, body after heading at paragraph 566
Source passage: SHARED must allow authorized administrators to maintain organizations, units, stakeholders and contacts. They must keep these records separate from login accounts and retain deactivation history.
Need: Proposed need: Maintain organizations and people. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR002 · Manage accounts and roles
SHARED must allow authorized administrators to manage account state, groups, memberships, roles and permissions through audited workflows. Open self-registration must remain disabled unless separately approved.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR002, body after heading at paragraph 569
Source passage: SHARED must allow authorized administrators to manage account state, groups, memberships, roles and permissions through audited workflows. Open self-registration must remain disabled unless separately approved.
Need: Proposed need: Manage accounts and roles. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR003 · Limit delegated powers
SHARED must apply the permitted scope and effective dates to every delegation and assignment. A delegate must not grant powers beyond those they may delegate.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR003, body after heading at paragraph 572
Source passage: SHARED must apply the permitted scope and effective dates to every delegation and assignment. A delegate must not grant powers beyond those they may delegate.
Need: Proposed need: Limit delegated powers. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR004 · Use standard secure sign in
SHARED must provide secure sign-in through an authentication service, including standard password hashing, lockout, expiring tokens and revocable sessions. Require multi-factor authentication for platform administrators, privileged access reviewers and other roles identified by the approved security policy.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR004, body after heading at paragraph 575
Source passage: SHARED must provide secure sign-in through an authentication service, including standard password hashing, lockout, expiring tokens and revocable sessions. Require multi-factor authentication for platform administrators, privileged access reviewers and other roles identified by the approved security policy.
Need: Proposed need: Use standard secure sign in. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR005 · Use the signed in user identity
SHARED must identify the acting user from validated sign-in on the server. An identity or scope supplied in a request must not be accepted as proof of permission.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR005, body after heading at paragraph 578
Source passage: SHARED must identify the acting user from validated sign-in on the server. An identity or scope supplied in a request must not be accepted as proof of permission.
Need: Proposed need: Use the signed in user identity. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR006 · Invite the intended user
SHARED must issue expiring, single-use invitations that activate only the intended account. Keep delivery, use and recovery states truthful; do not print invitation secrets in logs.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR006, body after heading at paragraph 581
Source passage: SHARED must issue expiring, single-use invitations that activate only the intended account. Keep delivery, use and recovery states truthful; do not print invitation secrets in logs.
Need: Proposed need: Invite the intended user. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR007 · Keep the user identity when changing workspace
SHARED must let an authorized administrator select a shared stakeholder context. SHARED must retain the actual acting account and check the chosen context's permissions.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR007, body after heading at paragraph 584
Source passage: SHARED must let an authorized administrator select a shared stakeholder context. SHARED must retain the actual acting account and check the chosen context's permissions.
Need: Proposed need: Keep the user identity when changing workspace. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR008 · Use one connected platform
SHARED must connect organizations, domains, geography, projects, evidence, contributions and discovery through shared identities and workflows.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR008, body after heading at paragraph 587
Source passage: SHARED must connect organizations, domains, geography, projects, evidence, contributions and discovery through shared identities and workflows.
Need: Proposed need: Use one connected platform. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR009 · Check the full access scope
SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR009, body after heading at paragraph 590
Source passage: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Need: Proposed need: Check the full access scope. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR010 · Let owners control sharing
SHARED must allow appointed sharing managers to choose owner-only or selected-stakeholder audiences within shared rules, including dataset overrides. Audit changes and prevent recipient re-sharing or self-delegation.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR010, body after heading at paragraph 593
Source passage: SHARED must allow appointed sharing managers to choose owner-only or selected-stakeholder audiences within shared rules, including dataset overrides. Audit changes and prevent recipient re-sharing or self-delegation.
Need: Proposed need: Let owners control sharing. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR011 · Place all stakeholders correctly
SHARED must retain the approved stakeholder branches and related participants through shared identities. The prototype currently groups these into 15 main branches. This is an editable starting configuration. Adding a participant must not create legal ownership, a login account or access automatically.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR011, body after heading at paragraph 596
Source passage: SHARED must retain the approved stakeholder branches and related participants through shared identities. The prototype currently groups these into 15 main branches. This is an editable starting configuration. Adding a participant must not create legal ownership, a login account or access automatically.
Need: Proposed need: Place all stakeholders correctly. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR012 · Keep separate owned base domains
SHARED must allow each owner to maintain its permitted base domains, subjects, attributes and connections. Forest and Wildlife must retain separate ownership. Shared subjects must use reviewed relationships.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR012, body after heading at paragraph 599
Source passage: SHARED must allow each owner to maintain its permitted base domains, subjects, attributes and connections. Forest and Wildlife must retain separate ownership. Shared subjects must use reviewed relationships.
Need: Proposed need: Keep separate owned base domains. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR013 · Configure useful workspaces
SHARED must provide configurable dashboard definitions, audiences and saved preferences. Register proposed products with their purpose, inputs, coverage, approval and acceptance needs; leave proposals inactive.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR013, body after heading at paragraph 602
Source passage: SHARED must provide configurable dashboard definitions, audiences and saved preferences. Register proposed products with their purpose, inputs, coverage, approval and acceptance needs; leave proposals inactive.
Need: Proposed need: Configure useful workspaces. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR014 · Maintain versioned domain packs
SHARED must allow appointed stewards to maintain reviewed domain packs containing schema definitions, vocabularies, units and project or deliverable templates.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR014, body after heading at paragraph 605
Source passage: SHARED must allow appointed stewards to maintain reviewed domain packs containing schema definitions, vocabularies, units and project or deliverable templates.
Need: Proposed need: Maintain versioned domain packs. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR015 · Allow safe configuration only
SHARED must limit configuration to reviewed field types, components, validation, vocabulary, geography and evidence definitions. Reject scripts, executable expressions and unknown properties.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR015, body after heading at paragraph 608
Source passage: SHARED must limit configuration to reviewed field types, components, validation, vocabulary, geography and evidence definitions. Reject scripts, executable expressions and unknown properties.
Need: Proposed need: Allow safe configuration only. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR016 · Keep the original form version
SHARED must keep the exact field definitions and form version used to validate each submitted section. Later template edits must not rewrite that submission.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR016, body after heading at paragraph 611
Source passage: SHARED must keep the exact field definitions and form version used to validate each submitted section. Later template edits must not rewrite that submission.
Need: Proposed need: Keep the original form version. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR017 · Separate editable settings from software changes
SHARED must allow new domains, subjects and attributes that use published supported storage profiles to be configured without deployment.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR017, body after heading at paragraph 614
Source passage: SHARED must allow new domains, subjects and attributes that use published supported storage profiles to be configured without deployment.
Need: Proposed need: Separate editable settings from software changes. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR018 · Maintain editable vocabularies
SHARED must support hierarchy, translations, effective dates, ordering, aliases and retirement in reference lists. Used identities and meanings must remain stable.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR018, body after heading at paragraph 617
Source passage: SHARED must support hierarchy, translations, effective dates, ordering, aliases and retirement in reference lists. Used identities and meanings must remain stable.
Need: Proposed need: Maintain editable vocabularies. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR019 · Allow several domain classifications
SHARED must link a controlled record to its primary domain and secondary classifications without copying its core record.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR019, body after heading at paragraph 620
Source passage: SHARED must link a controlled record to its primary domain and secondary classifications without copying its core record.
Need: Proposed need: Allow several domain classifications. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR020 · Keep business terms in configuration
SHARED must store the initial domain names, field descriptions and allowed choices as editable settings. They must not be fixed in screen code or supplied as sample business records.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR020, body after heading at paragraph 623
Source passage: SHARED must store the initial domain names, field descriptions and allowed choices as editable settings. They must not be fixed in screen code or supplied as sample business records.
Need: Proposed need: Keep business terms in configuration. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR021 · Review meanings and impacts
SHARED must reuse existing meanings, fields and units where they are truly the same. Before merging definitions or publishing a change, an authorized reviewer must check possible duplicates and affected records. Similar labels do not prove equal meaning.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR021, body after heading at paragraph 626
Source passage: SHARED must reuse existing meanings, fields and units where they are truly the same. Before merging definitions or publishing a change, an authorized reviewer must check possible duplicates and affected records. Similar labels do not prove equal meaning.
Need: Proposed need: Review meanings and impacts. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU and appointed institutional access/domain owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C02; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR022 · Support several geography schemes
SHARED must allow appointed stewards to configure independent geography schemes and levels rather than force all places into one hierarchy.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR022, body after heading at paragraph 661
Source passage: SHARED must allow appointed stewards to configure independent geography schemes and levels rather than force all places into one hierarchy.
Need: Proposed need: Support several geography schemes. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR023 · Keep place identity and source
SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR023, body after heading at paragraph 664
Source passage: SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Need: Proposed need: Keep place identity and source. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR024 · Link overlapping places
SHARED must support reviewed hierarchy, containment, overlap and many-to-many links between schemes.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR024, body after heading at paragraph 667
Source passage: SHARED must support reviewed hierarchy, containment, overlap and many-to-many links between schemes.
Need: Proposed need: Link overlapping places. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR025 · Preserve boundary history
SHARED must preserve historical references and prevent deletion of used meanings when a place is replaced, split, merged or retired.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR025, body after heading at paragraph 670
Source passage: SHARED must preserve historical references and prevent deletion of used meanings when a place is replaced, split, merged or retired.
Need: Proposed need: Preserve boundary history. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR026 · Validate spatial input
SHARED must check coordinate system, bounds, type, validity, topology, complexity and safe query limits. Unsupported input must fail clearly.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR026, body after heading at paragraph 673
Source passage: SHARED must check coordinate system, bounds, type, validity, topology, complexity and safe query limits. Unsupported input must fail clearly.
Need: Proposed need: Validate spatial input. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR027 · Review boundary changes
SHARED must enforce the configured Draft, Review, Active and Retired lifecycle for boundaries. High-impact changes need impact preview and independent approval.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR027, body after heading at paragraph 676
Source passage: SHARED must enforce the configured Draft, Review, Active and Retired lifecycle for boundaries. High-impact changes need impact preview and independent approval.
Need: Proposed need: Review boundary changes. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR028 · Search GN divisions within safe limits
SHARED must search GN areas through the shared paged geography reader. Keep timeout, missing and denied responses distinct from a valid empty list.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR028, body after heading at paragraph 679
Source passage: SHARED must search GN areas through the shared paged geography reader. Keep timeout, missing and denied responses distinct from a valid empty list.
Need: Proposed need: Search GN divisions within safe limits. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR063 · Describe spatial sources
SHARED must retain each spatial layer version's source type, geometry or raster descriptive information, coordinate system, scale or resolution, coverage, owner and classification.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR063, body after heading at paragraph 682
Source passage: SHARED must retain each spatial layer version's source type, geometry or raster descriptive information, coordinate system, scale or resolution, coverage, owner and classification.
Need: Proposed need: Describe spatial sources. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR064 · Save permitted map settings
SHARED must make approved map styles, legends, layer groups and saved map workspaces refer to the shared permitted layers. Recheck withdrawn source access.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR064, body after heading at paragraph 685
Source passage: SHARED must make approved map styles, legends, layer groups and saved map workspaces refer to the shared permitted layers. Recheck withdrawn source access.
Need: Proposed need: Save permitted map settings. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR065 · Reuse one spatial catalogue
SHARED must connect layers to domains, datasets, documents, projects, interventions and geographies without another GIS registry.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR065, body after heading at paragraph 688
Source passage: SHARED must connect layers to domains, datasets, documents, projects, interventions and geographies without another GIS registry.
Need: Proposed need: Reuse one spatial catalogue. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR066 · Protect location disclosure
SHARED must enforce device, volume and location-disclosure limits in web and mobile maps. Sensitive exact locations must be hidden or generalized according to approved rules.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR066, body after heading at paragraph 691
Source passage: SHARED must enforce device, volume and location-disclosure limits in web and mobile maps. Sensitive exact locations must be hidden or generalized according to approved rules.
Need: Proposed need: Protect location disclosure. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR067 · Exclude known demonstration features
SHARED must exclude positively identified test and demonstration features from operational maps while preserving their history. Unknown origin must not be relabelled real.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR067, body after heading at paragraph 694
Source passage: SHARED must exclude positively identified test and demonstration features from operational maps while preserving their history. Unknown origin must not be relabelled real.
Need: Proposed need: Exclude known demonstration features. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR068 · Keep navigation and large maps simple
SHARED must use the shared grouped menu, context and progressive layer loading. Cancel old requests and distinguish missing, denied, failed and valid empty results.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR068, body after heading at paragraph 697
Source passage: SHARED must use the shared grouped menu, context and progressive layer loading. Cancel old requests and distinguish missing, denied, failed and valid empty results.
Need: Proposed need: Keep navigation and large maps simple. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR069 · Provide bounded vector exploration
SHARED must support the specified approximate buffer, loaded-feature proximity, selected-polygon overlap and area tools with method, units, inputs and limits.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR069, body after heading at paragraph 700
Source passage: SHARED must support the specified approximate buffer, loaded-feature proximity, selected-polygon overlap and area tools with method, units, inputs and limits.
Need: Proposed need: Provide bounded vector exploration. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR070 · Use genuine points for point methods
SHARED must use actual points and retain scale, denominators and non-estimable states for clustering, record-density grids and exploratory hotspot counts. Do not invent point centres or risk classes.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR070, body after heading at paragraph 703
Source passage: SHARED must use actual points and retain scale, denominators and non-estimable states for clustering, record-density grids and exploratory hotspot counts. Do not invent point centres or risk classes.
Need: Proposed need: Use genuine points for point methods. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR071 · Compare compatible raster cells
SHARED must check coordinate system, grid alignment, units, class meaning and missing cells before supported raster preview, swipe, native-cell summary or change analysis.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR071, body after heading at paragraph 706
Source passage: SHARED must check coordinate system, grid alignment, units, class meaning and missing cells before supported raster preview, swipe, native-cell summary or change analysis.
Need: Proposed need: Compare compatible raster cells. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR072 · Retain an exploratory receipt
SHARED must keep source versions, context, parameters, fingerprints, limits and outputs. Bound background work, support cancellation and invalidate results after source change.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR072, body after heading at paragraph 709
Source passage: SHARED must keep source versions, context, parameters, fingerprints, limits and outputs. Bound background work, support cancellation and invalidate results after source change.
Need: Proposed need: Retain an exploratory receipt. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR073 · Retain normalized spatial sources
SHARED must use the shared source and version workflow for exact lawful originals and supported normalized points or native raster cells. Preserve coordinates, source dates and missing cells.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR073, body after heading at paragraph 712
Source passage: SHARED must use the shared source and version workflow for exact lawful originals and supported normalized points or native raster cells. Preserve coordinates, source dates and missing cells.
Need: Proposed need: Retain normalized spatial sources. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR074 · Review spatial release separately
SHARED must keep a pending spatial layer unpublished during ingestion. Apply archive, geometry, extent and supported transformation controls. General conversion, national tiling or every GIS file type must not be claimed.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR074, body after heading at paragraph 715
Source passage: SHARED must keep a pending spatial layer unpublished during ingestion. Apply archive, geometry, extent and supported transformation controls. General conversion, national tiling or every GIS file type must not be claimed.
Need: Proposed need: Review spatial release separately. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR075 · Keep weather source identities
SHARED must retain source product, variable, location, unit, observation period, receipt time, issue time and forecast validity where supplied.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR075, body after heading at paragraph 718
Source passage: SHARED must retain source product, variable, location, unit, observation period, receipt time, issue time and forecast validity where supplied.
Need: Proposed need: Keep weather source identities. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C03; C04; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR076 · Show missing and stale weather honestly
SHARED must show overdue or failed source acquisition and expired retained forecasts in source-refresh views. Unknown source or period must remain unknown.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR076, body after heading at paragraph 721
Source passage: SHARED must show overdue or failed source acquisition and expired retained forecasts in source-refresh views. Unknown source or period must remain unknown.
Need: Proposed need: Show missing and stale weather honestly. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C03; C04; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR077 · Keep retained rainfall at its actual scale
SHARED must retain the original grid location, period, units, references and origin of retained rainfall source series. Do not invent a GN assignment or new station.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR077, body after heading at paragraph 724
Source passage: SHARED must retain the original grid location, period, units, references and origin of retained rainfall source series. Do not invent a GN assignment or new station.
Need: Proposed need: Keep retained rainfall at its actual scale. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C03; C04; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR078 · Do not invent the GN time series
SHARED must require suitable dated records or an approved allocation method for a complete GN rainfall and cultivation comparison. An undated classification or district statistic cannot supply five annual GN totals.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR078, body after heading at paragraph 727
Source passage: SHARED must require suitable dated records or an approved allocation method for a complete GN rainfall and cultivation comparison. An undated classification or district statistic cannot supply five annual GN totals.
Need: Proposed need: Do not invent the GN time series. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C03; C04; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR079 · Separate evidence from warnings
SHARED must require the relevant accepted method, inputs and authority before presenting operational hazard, drought, adaptation or warning outputs. Recorded context must not become an official warning automatically.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR079, body after heading at paragraph 730
Source passage: SHARED must require the relevant accepted method, inputs and authority before presenting operational hazard, drought, adaptation or warning outputs. Recorded context must not become an official warning automatically.
Need: Proposed need: Separate evidence from warnings. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C03; C04; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR080 · Keep farming identities and plots
SHARED must reuse society or farmer-group profiles, members, farm plots and plot-crop records with their owner, source, area and permitted review states.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR080, body after heading at paragraph 733
Source passage: SHARED must reuse society or farmer-group profiles, members, farm plots and plot-crop records with their owner, source, area and permitted review states.
Need: Proposed need: Keep farming identities and plots. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed sector/programme data owner and method specialist; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C04; E01; E02
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR081 · Record farm work and issues
SHARED must link farming activities, problems, actions and evidence to the relevant plot, crop, project and workflow.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR081, body after heading at paragraph 736
Source passage: SHARED must link farming activities, problems, actions and evidence to the relevant plot, crop, project and workflow.
Need: Proposed need: Record farm work and issues. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed sector/programme data owner and method specialist; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C04; E01; E02
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-001 · Register Geographic Information Types
Each geographic record type must identify its owning institution, domain, subject, business object, allowed geometry, required and optional fields, place and time rules, source and evidence, validation, review workflow, map style, classification and access. Authorised stewards configure the type through the shared definitions.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-001, body after heading at paragraph 741
Source passage: Each geographic record type must identify its owning institution, domain, subject, business object, allowed geometry, required and optional fields, place and time rules, source and evidence, validation, review workflow, map style, classification and access. Authorised stewards configure the type through the shared definitions.
Need: Proposed need: Register Geographic Information Types. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-002 · Create Geographic Records from a Map
Authorised users must select the domain and record type, then choose an existing area or feature, enter coordinates, drop a point, or draw a line, polygon or supported multipart feature. Show only applicable fields and save the geometry or reference as a draft with the related business information.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-002, body after heading at paragraph 744
Source passage: Authorised users must select the domain and record type, then choose an existing area or feature, enter coordinates, drop a point, or draw a line, polygon or supported multipart feature. Show only applicable fields and save the geometry or reference as a draft with the related business information.
Need: Proposed need: Create Geographic Records from a Map. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-003 · Record Unknown or Approximate Locations
Keep a known administrative area separate from the actual occurrence or affected extent. Allow an area-only record when a precise location is unknown. Retain positional accuracy, uncertainty and source description for approximate points. Never invent coordinates, centroids or polygons to satisfy a field.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-003, body after heading at paragraph 747
Source passage: Keep a known administrative area separate from the actual occurrence or affected extent. Allow an area-only record when a precise location is unknown. Retain positional accuracy, uncertainty and source description for approximate points. Never invent coordinates, centroids or polygons to satisfy a field.
Need: Proposed need: Record Unknown or Approximate Locations. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-004 · Support Different Geographic Roles
One record may have several geographic representations: reported location, observed extent, surveyed footprint, investigation area, model assessment, proposed intervention and monitoring area. Each representation must retain its role, source, applicable period, accuracy and version. Do not silently combine these roles.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-004, body after heading at paragraph 750
Source passage: One record may have several geographic representations: reported location, observed extent, surveyed footprint, investigation area, model assessment, proposed intervention and monitoring area. Each representation must retain its role, source, applicable period, accuracy and version. Do not silently combine these roles.
Need: Proposed need: Support Different Geographic Roles. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-005 · Use Domain-Specific Attributes
Use the domain owner's published field definitions and reuse equivalent fields. Incident, wildlife, crop suitability and other record types may need different attributes and review rules. The owner confirms the field meanings, required state, units and allowed values before publication.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-005, body after heading at paragraph 753
Source passage: Use the domain owner's published field definitions and reuse equivalent fields. Incident, wildlife, crop suitability and other record types may need different attributes and review rules. The owner confirms the field meanings, required state, units and allowed values before publication.
Need: Proposed need: Use Domain-Specific Attributes. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-006 · Accept Multiple Geographic Data Sources
Support approved manual drawing, field and mobile surveys, coordinate entry, existing feature selection, GIS imports, institutional APIs and remote-sensing products. AI-suggested geographic references require the approved document-processing route. Every route uses shared source registration, mapping, validation and review.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-006, body after heading at paragraph 756
Source passage: Support approved manual drawing, field and mobile surveys, coordinate entry, existing feature selection, GIS imports, institutional APIs and remote-sensing products. AI-suggested geographic references require the approved document-processing route. Every route uses shared source registration, mapping, validation and review.
Need: Proposed need: Accept Multiple Geographic Data Sources. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-007 · Validate Geographic Information
Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-007, body after heading at paragraph 759
Source passage: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Need: Proposed need: Validate Geographic Information. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-008 · Review Geographic Records
Reviewers must inspect the submitted geometry, original source, field mappings, accuracy, related records, existing layers, validation, earlier versions and evidence. Record acceptance, return, rejection or required correction under the approved workflow. Technical validity alone cannot approve a geographic feature.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-008, body after heading at paragraph 762
Source passage: Reviewers must inspect the submitted geometry, original source, field mappings, accuracy, related records, existing layers, validation, earlier versions and evidence. Record acceptance, return, rejection or required correction under the approved workflow. Technical validity alone cannot approve a geographic feature.
Need: Proposed need: Review Geographic Records. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-009 · Preserve Source Ownership
Preserve the source institution, custodian, classification and permitted audience of every geographic claim. Different institutions may report on the same occurrence. Reviewed matching may link the reports without deleting originals or transferring ownership.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-009, body after heading at paragraph 765
Source passage: Preserve the source institution, custodian, classification and permitted audience of every geographic claim. Different institutions may report on the same occurrence. Reviewed matching may link the reports without deleting originals or transferring ownership.
Need: Proposed need: Preserve Source Ownership. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-010 · Maintain Geographic History
Preserve corrections, earlier geometry versions and reasons. A later surveyed footprint links to the original approximate record. Authorised users can inspect the historical evidence and change history.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-010, body after heading at paragraph 768
Source passage: Preserve corrections, earlier geometry versions and reasons. A later surveyed footprint links to the original approximate record. Authorised users can inspect the historical evidence and change history.
Need: Proposed need: Maintain Geographic History. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-011 · Support Geographic Time Periods
Keep occurrence, observation, reporting, survey, assessment, validity, entry and revision times distinct where relevant. Allow historical and reporting-period filters. A past flood extent must not be displayed as a current flood simply because its record is opened.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-011, body after heading at paragraph 771
Source passage: Keep occurrence, observation, reporting, survey, assessment, validity, entry and revision times distinct where relevant. Allow historical and reporting-period filters. A past flood extent must not be displayed as a current flood simply because its record is opened.
Need: Proposed need: Support Geographic Time Periods. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-012 · Reuse Existing GIS Layers
Expose permitted accepted records through the shared Map Explorer and spatial catalogue. Reuse existing layers, styles, geography references and services. Use governed feature collections where appropriate rather than a new catalogue, engine or physical layer for every institution or event.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-012, body after heading at paragraph 774
Source passage: Expose permitted accepted records through the shared Map Explorer and spatial catalogue. Reuse existing layers, styles, geography references and services. Use governed feature collections where appropriate rather than a new catalogue, engine or physical layer for every institution or event.
Need: Proposed need: Reuse Existing GIS Layers. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-013 · Configure Map Symbols and Legends
Configure symbols, legends and styles for record types and geographic roles. Distinguish incidents, surveyed extents, suitability assessments, proposed interventions and unreviewed observations. Colour alone must not communicate approval, severity, hazard or suitability.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-013, body after heading at paragraph 777
Source passage: Configure symbols, legends and styles for record types and geographic roles. Distinguish incidents, surveyed extents, suitability assessments, proposed interventions and unreviewed observations. Colour alone must not communicate approval, severity, hazard or suitability.
Need: Proposed need: Configure Map Symbols and Legends. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-014 · Support Geographic Analysis
Permit supported area, distance, overlap, intersection, containment, proximity, administrative aggregation, temporal comparison, counts and overlay analyses. Retain the actual source geometry, method, units, limits and derived-result evidence. Do not imply unsupported scientific accuracy.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-014, body after heading at paragraph 780
Source passage: Permit supported area, distance, overlap, intersection, containment, proximity, administrative aggregation, temporal comparison, counts and overlay analyses. Retain the actual source geometry, method, units, limits and derived-result evidence. Do not imply unsupported scientific accuracy.
Need: Proposed need: Support Geographic Analysis. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-015 · Connect Geographic Records to Other Modules
Reuse the same accepted geographic identity across permitted map, location profile, domain dashboard, expert, planning, decision, project and PMU views. Links must preserve the governed source, version and access rules.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-015, body after heading at paragraph 783
Source passage: Reuse the same accepted geographic identity across permitted map, location profile, domain dashboard, expert, planning, decision, project and PMU views. Links must preserve the governed source, version and access rules.
Need: Proposed need: Connect Geographic Records to Other Modules. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-016 · Support Data Maintenance
Provide the appropriate authorised edit, field survey, API, GIS import or source-synchronisation route for each record or layer. Preserve source and geometry history. Operational users must not edit database records directly.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-016, body after heading at paragraph 786
Source passage: Provide the appropriate authorised edit, field survey, API, GIS import or source-synchronisation route for each record or layer. Preserve source and geometry history. Operational users must not edit database records directly.
Need: Proposed need: Support Data Maintenance. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-017 · Support responsive geographic collection
Within the agreed responsive field journey, allow authorised users to capture geographic points, accuracy, permitted geometry, photographs and actual observation time where the selected device supports them. An additional field-access channel and offline drafts are proposed options under C01, C06 and C07. If selected, protect drafts and synchronise through the common authenticated service interfaces. Synchronisation alone must not publish an unreviewed record.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-017, body after heading at paragraph 789; correction request IR-007/IR-001 and Version 1.6 SH-GEO-FEAT-017
Source passage: Within the agreed mobile scope, allow authorised field users to capture GPS points, accuracy, geometry, photographs and actual observation time. Protect offline drafts and synchronise through the common API. Synchronisation alone must not publish an unreviewed record.
Need: Proposed need: Support Mobile Geographic Collection. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04; C06; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-018 · Show Geographic Data Quality and Status
Show source, actual observation or occurrence time, geometry role, accuracy, review and approval state, version and real, reference or demonstration origin in maps and record details. Keep unavailable information explicitly unknown.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-018, body after heading at paragraph 792
Source passage: Show source, actual observation or occurrence time, geometry role, accuracy, review and approval state, version and real, reference or demonstration origin in maps and record details. Keep unavailable information explicitly unknown.
Need: Proposed need: Show Geographic Data Quality and Status. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-019 · Protect restricted geographic information
Apply complete institutional ownership and permission rules to geographic features, service responses, maps, search, counts and exports. Protect sensitive wildlife locations, personal information and restricted records. For fresh public access, use one shared eligibility rule for publication state, classification, audience, required source identity, exact permitted source version, approved use rights, expiry and source or citation dependencies. Re-evaluate on read and export, including dependent cached outputs. Suppress public access when a required dependency is withdrawn, expired, restricted, missing, cyclic or no longer authorised for the requested use. Do not assume the newest version is approved or reject an older version that remains explicitly permitted. Preserve authorised internal records, provenance and history. Previously downloaded copies outside SHARED cannot be recalled.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-019, body after heading at paragraph 795; correction request IR-007/IR-001 and Version 1.6 SH-GEO-FEAT-019
Source passage: Apply complete institutional ownership and permission rules to geographic features, API responses, maps, search, counts and exports. Protect sensitive wildlife locations, personal information and restricted records. Public maps contain only information allowed for their audience.
Need: Proposed need: Protect Restricted Geographic Information. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
SH-GEO-FEAT-020 · Distinguish Facts from Assessments and Warnings
Distinguish reported from verified landslides, thermal detections from confirmed fires, forecasts from observed flood extents, suitability scores from legal land-use decisions, proposed from implemented activities, and exploratory from accepted scientific results. Official warnings, regulatory decisions and expert conclusions require their own authority and approval.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, SH-GEO-FEAT-020, body after heading at paragraph 798
Source passage: Distinguish reported from verified landslides, thermal detections from confirmed fires, forecasts from observed flood extents, suitability scores from legal land-use decisions, proposed from implemented activities, and exploratory from accepted scientific results. Official warnings, regulatory decisions and expert conclusions require their own authority and approval.
Need: Proposed need: Distinguish Facts from Assessments and Warnings. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed geography/source custodians and institutional data owners; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP2
Proposed release: Proposed first release via WP2
Accepted release: Not decided
Decision references: C01; C11; C02; C03; C04; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR094 · Build reusable report questions
SHARED must allow permitted users to select bounded approved templates, fields, filters and aggregations. Do not accept raw database commands, scripts or arbitrary executable formulas.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR094, body after heading at paragraph 866
Source passage: SHARED must allow permitted users to select bounded approved templates, fields, filters and aggregations. Do not accept raw database commands, scripts or arbitrary executable formulas.
Need: Proposed need: Build reusable report questions. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR095 · Keep report sources and access rules
SHARED must retain source and version, time, scope and reproducible inputs for queries and executions. Export and later reads must recheck permission.
Source class: Documented consultation input
Evidence locator: SRS Version 1.5, FR095, body after heading at paragraph 869
Source passage: SHARED must retain source and version, time, scope and reproducible inputs for queries and executions. Export and later reads must recheck permission.
Need: Proposed need: Keep report sources and access rules. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR096 · Review how datasets will be combined
SHARED must retain a versioned join plan identifying exact input versions, keys, number of matching records, time alignment, meaning of one output row, missing-row policy, purpose and evidence.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR096, body after heading at paragraph 872
Source passage: SHARED must retain a versioned join plan identifying exact input versions, keys, number of matching records, time alignment, meaning of one output row, missing-row policy, purpose and evidence.
Need: Proposed need: Review how datasets will be combined. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR097 · Show unmatched and invalid inputs
SHARED must preserve unmatched rows and mapping or approval checks when joining datasets. Reject duplicate keys, unsupported joins, changed approval state and work beyond limits.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR097, body after heading at paragraph 875
Source passage: SHARED must preserve unmatched rows and mapping or approval checks when joining datasets. Reject duplicate keys, unsupported joins, changed approval state and work beyond limits.
Need: Proposed need: Show unmatched and invalid inputs. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR098 · Save report definitions and results
SHARED must reuse private versioned report definitions and saved report runs, retaining exact source values, units, filters, review and calculation. Editing or refreshing creates a new version or execution.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR098, body after heading at paragraph 878
Source passage: SHARED must reuse private versioned report definitions and saved report runs, retaining exact source values, units, filters, review and calculation. Editing or refreshing creates a new version or execution.
Need: Proposed need: Save report definitions and results. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR099 · Use suitable visuals and source maps
SHARED must use suitable comparisons, date series and distributions with units and source coverage.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR099, body after heading at paragraph 881
Source passage: SHARED must use suitable comparisons, date series and distributions with units and source coverage.
Need: Proposed need: Use suitable visuals and source maps. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR100 · Export reports with sources and review history
SHARED must retain source and review evidence in supported spreadsheet, CSV, JSON and print outputs. Formal report versions use saved results, list of supporting evidences and reviewed publication.
Source class: Documented consultation input
Evidence locator: SRS Version 1.5, FR100, body after heading at paragraph 884
Source passage: SHARED must retain source and review evidence in supported spreadsheet, CSV, JSON and print outputs. Formal report versions use saved results, list of supporting evidences and reviewed publication.
Need: Proposed need: Export reports with sources and review history. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR101 · Show what a decision needs
SHARED must show each decision question, exact context, required data, method, authority and outcome-monitoring needs. Missing data, expert decisions and governance approval must have named owners.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR101, body after heading at paragraph 887
Source passage: SHARED must show each decision question, exact context, required data, method, authority and outcome-monitoring needs. Missing data, expert decisions and governance approval must have named owners.
Need: Proposed need: Show what a decision needs. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR102 · Calculate an approved criteria score
SHARED must use explicit reviewed weights, best/worst anchors, exact source units and required values in the criteria calculation within defined limits. Missing evidence blocks the score; equal scores keep equal rank.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR102, body after heading at paragraph 890
Source passage: SHARED must use explicit reviewed weights, best/worst anchors, exact source units and required values in the criteria calculation within defined limits. Missing evidence blocks the score; equal scores keep equal rank.
Need: Proposed need: Calculate an approved criteria score. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR103 · Check differences and thresholds safely
SHARED must check compatible unit, place and period before plan/actual arithmetic and withhold percentage variance when the plan is zero. Numeric rule checks require explicit reviewed thresholds and output meaning.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR103, body after heading at paragraph 893
Source passage: SHARED must check compatible unit, place and period before plan/actual arithmetic and withhold percentage variance when the plan is zero. Numeric rule checks require explicit reviewed thresholds and output meaning.
Need: Proposed need: Check differences and thresholds safely. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR104 · Route a reviewed finding only when configured
SHARED must allow an approved enabled routing policy to create a shared review case with named people, severity and deadline. Case creation and result publication must succeed or fail together.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR104, body after heading at paragraph 896
Source passage: SHARED must allow an approved enabled routing policy to create a shared review case with named people, severity and deadline. Case creation and result publication must succeed or fail together.
Need: Proposed need: Route a reviewed finding only when configured. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR105 · Record the human decision
SHARED must retain each case's problem, evidence, assignment, options, consultation, recommendation, authority, rationale, actions, outcome verification and closure or reopening history.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR105, body after heading at paragraph 899
Source passage: SHARED must retain each case's problem, evidence, assignment, options, consultation, recommendation, authority, rationale, actions, outcome verification and closure or reopening history.
Need: Proposed need: Record the human decision. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR106 · Use actual evidence and current guidance
SHARED must use actual permitted records for decision preparation. When considering which option fits the local circumstances, SHARED must reuse current independently reviewed published knowledge and exact case citations.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR106, body after heading at paragraph 902
Source passage: SHARED must use actual permitted records for decision preparation. When considering which option fits the local circumstances, SHARED must reuse current independently reviewed published knowledge and exact case citations.
Need: Proposed need: Use actual evidence and current guidance. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR107 · Require independent review and approved methods
SHARED must enforce required independence between decision roles. Generic scoring and policy checks must not claim scientific suitability, legal eligibility, entitlement or payment authority.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR107, body after heading at paragraph 905
Source passage: SHARED must enforce required independence between decision roles. Generic scoring and policy checks must not claim scientific suitability, legal eligibility, entitlement or payment authority.
Need: Proposed need: Require independent review and approved methods. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Report/decision owner and appointed method/data reviewers; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C04; C05; E01
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR108 · Register the programme or project
SHARED must keep project type, funder, lead, partners, objectives, dates, lifecycle state and reporting obligations within permitted scope.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR108, body after heading at paragraph 940
Source passage: SHARED must keep project type, funder, lead, partners, objectives, dates, lifecycle state and reporting obligations within permitted scope.
Need: Proposed need: Register the programme or project. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR109 · Connect domains and areas once
SHARED must link one project to several domains and places through explicit applicability relationships tied to that project revision.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR109, body after heading at paragraph 943
Source passage: SHARED must link one project to several domains and places through explicit applicability relationships tied to that project revision.
Need: Proposed need: Connect domains and areas once. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR110 · Organize implementation
SHARED must maintain components, activities, interventions, sites, responsible organizations, schedules and implementation state.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR110, body after heading at paragraph 946
Source passage: SHARED must maintain components, activities, interventions, sites, responsible organizations, schedules and implementation state.
Need: Proposed need: Organize implementation. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR111 · Link project evidence
SHARED must preserve source and access rules when linking projects or interventions to documents, datasets, indicators, layers, submissions and evidence.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR111, body after heading at paragraph 949
Source passage: SHARED must preserve source and access rules when linking projects or interventions to documents, datasets, indicators, layers, submissions and evidence.
Need: Proposed need: Link project evidence. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR112 · Onboard ongoing and completed projects
SHARED must retain a reviewed source baseline, original project identifier, baseline date and known quality findings when onboarding an ongoing or completed project. The import must preserve known history without inventing milestones.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR112, body after heading at paragraph 952
Source passage: SHARED must retain a reviewed source baseline, original project identifier, baseline date and known quality findings when onboarding an ongoing or completed project. The import must preserve known history without inventing milestones.
Need: Proposed need: Onboard ongoing and completed projects. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR113 · Keep versions of major project changes
SHARED must create linked revisions for material changes to active projects instead of overwriting approved project or domain profiles.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR113, body after heading at paragraph 955
Source passage: SHARED must create linked revisions for material changes to active projects instead of overwriting approved project or domain profiles.
Need: Proposed need: Keep versions of major project changes. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR114 · Follow the project from setup to closure
SHARED must use one persisted plan from intake and configuration through review, activation, execution, monitoring, decision, reporting, closure and archive.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR114, body after heading at paragraph 958
Source passage: SHARED must use one persisted plan from intake and configuration through review, activation, execution, monitoring, decision, reporting, closure and archive.
Need: Proposed need: Follow the project from setup to closure. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR115 · Record each project step and its owner
SHARED must distinguish setting up a new project from importing an ongoing or completed project. Each applicable step must keep status, owner, due date, dependencies, validation and completion evidence.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR115, body after heading at paragraph 961
Source passage: SHARED must distinguish setting up a new project from importing an ongoing or completed project. Each applicable step must keep status, owner, due date, dependencies, validation and completion evidence.
Need: Proposed need: Record each project step and its owner. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR116 · Keep task submissions and review records linked
SHARED must keep obligation definition, occurrence, fixed submitted version, schema section, artifact and review decision separately linked.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR116, body after heading at paragraph 964
Source passage: SHARED must keep obligation definition, occurrence, fixed submitted version, schema section, artifact and review decision separately linked.
Need: Proposed need: Keep task submissions and review records linked. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR117 · Generate scheduled tasks once
SHARED must support one-time and recurring obligations. Generate occurrences repeatably and derive overdue from the actual due date and state.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR117, body after heading at paragraph 967
Source passage: SHARED must support one-time and recurring obligations. Generate occurrences repeatably and derive overdue from the actual due date and state.
Need: Proposed need: Generate scheduled tasks once. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR118 · Record who must deliver each item
SHARED must record each assignment's responsible organization, group or person, component, domain, geography, dates, dependencies, acceptance criteria, authority and evidence needs.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR118, body after heading at paragraph 970
Source passage: SHARED must record each assignment's responsible organization, group or person, component, domain, geography, dates, dependencies, acceptance criteria, authority and evidence needs.
Need: Proposed need: Record who must deliver each item. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR119 · Return and correct with a reason
SHARED must validate against the original form version. Retain review findings, return reasons, corrected versions and resubmission. Blocking findings must prevent acceptance.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR119, body after heading at paragraph 973
Source passage: SHARED must validate against the original form version. Retain review findings, return reasons, corrected versions and resubmission. Blocking findings must prevent acceptance.
Need: Proposed need: Return and correct with a reason. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR120 · Show only permitted assigned work
SHARED must prevent My work and review queues from disclosing differently scoped work through lists, counts, maps, files or exports.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR120, body after heading at paragraph 976
Source passage: SHARED must prevent My work and review queues from disclosing differently scoped work through lists, counts, maps, files or exports.
Need: Proposed need: Show only permitted assigned work. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR121 · Keep required review independent
SHARED must use configured reviewer assignments and retained decisions. Protect high-impact publication, role, geography, taxonomy and import changes with independent approval.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR121, body after heading at paragraph 979
Source passage: SHARED must use configured reviewer assignments and retained decisions. Protect high-impact publication, role, geography, taxonomy and import changes with independent approval.
Need: Proposed need: Keep required review independent. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR122 · Connect protected feedback to action
SHARED must link an exact permitted feedback submission to the shared decision case with compatible revision, domain and place. Keep original content, review and later response evidence.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR122, body after heading at paragraph 982
Source passage: SHARED must link an exact permitted feedback submission to the shared decision case with compatible revision, domain and place. Keep original content, review and later response evidence.
Need: Proposed need: Connect protected feedback to action. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR123 · Approve the monitoring plan
SHARED must retain reviewed indicators, baseline, target, period, place, responsibility, sources, calculation, quality and approval for each active project-domain monitoring context.
Source class: Documented consultation input
Evidence locator: SRS Version 1.5, FR123, body after heading at paragraph 985
Source passage: SHARED must retain reviewed indicators, baseline, target, period, place, responsibility, sources, calculation, quality and approval for each active project-domain monitoring context.
Need: Proposed need: Approve the monitoring plan. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR124 · Allow honest baseline and target states
SHARED must support unknown or descriptive baselines where permitted, dated targets, denominators, assumptions and verification needs. Keep targets separate from observed results.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR124, body after heading at paragraph 988
Source passage: SHARED must support unknown or descriptive baselines where permitted, dated targets, denominators, assumptions and verification needs. Keep targets separate from observed results.
Need: Proposed need: Allow honest baseline and target states. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR125 · Execute a repeatable reviewed method
SHARED must generate monitoring results only through approved versioned calculations. Keep exact input and output history, steps, units, parameters, review and execution evidence.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR125, body after heading at paragraph 991
Source passage: SHARED must generate monitoring results only through approved versioned calculations. Keep exact input and output history, steps, units, parameters, review and execution evidence.
Need: Proposed need: Execute a repeatable reviewed method. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR126 · Reconcile closure across the project
SHARED must reconcile delivery, monitoring, decisions, data, access, knowledge, handover, retention and post-project obligations during required closure.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR126, body after heading at paragraph 994
Source passage: SHARED must reconcile delivery, monitoring, decisions, data, access, knowledge, handover, retention and post-project obligations during required closure.
Need: Proposed need: Reconcile closure across the project. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR127 · Verify or waive each closure check properly
SHARED must record each closure check's owner, deadline, evidence and independent verification or permitted reasoned waiver. Retain unchangeable status history.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR127, body after heading at paragraph 997
Source passage: SHARED must record each closure check's owner, deadline, evidence and independent verification or permitted reasoned waiver. Retain unchangeable status history.
Need: Proposed need: Verify or waive each closure check properly. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR128 · Allow closure only after required checks
SHARED must enforce the approved closure plan and frozen list of required closure checks before a project becomes Closed or Archived. This gate applies through every supported service operation.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR128, body after heading at paragraph 1000
Source passage: SHARED must enforce the approved closure plan and frozen list of required closure checks before a project becomes Closed or Archived. This gate applies through every supported service operation.
Need: Proposed need: Allow closure only after required checks. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR090 · Reuse asset and connection records
SHARED must extend shared structure or intervention records with asset profiles. Keep condition, capacity, custody and directed source-reported connections with evidence.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR090, body after heading at paragraph 1003
Source passage: SHARED must extend shared structure or intervention records with asset profiles. Keep condition, capacity, custody and directed source-reported connections with evidence.
Need: Proposed need: Reuse asset and connection records. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR091 · Retain handover and maintenance evidence
SHARED must link asset handover and maintenance responsibilities to the required receiving-institution evidence and shared closure process.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR091, body after heading at paragraph 1006
Source passage: SHARED must link asset handover and maintenance responsibilities to the required receiving-institution evidence and shared closure process.
Need: Proposed need: Retain handover and maintenance evidence. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C10; C12
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR086 · Reuse participant identities
SHARED must extend shared identities with programme participant profiles and retain their owner, domain, geography, source and origin. Keep shared departmental accounts separate from individual beneficiaries.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR086, body after heading at paragraph 1041
Source passage: SHARED must extend shared identities with programme participant profiles and retain their owner, domain, geography, source and origin. Keep shared departmental accounts separate from individual beneficiaries.
Need: Proposed need: Reuse participant identities. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed institutional service/knowledge owner and publication reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C05; C09
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR087 · Record support and training history
SHARED must retain support episodes with their programme, provider, type, source-reported status and known amounts, currency, quantities and dates. Prior-assistance checks must respect lawful access.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR087, body after heading at paragraph 1044
Source passage: SHARED must retain support episodes with their programme, provider, type, source-reported status and known amounts, currency, quantities and dates. Prior-assistance checks must respect lawful access.
Need: Proposed need: Record support and training history. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed institutional service/knowledge owner and publication reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C05; C09
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR088 · Connect products producers and buyers
SHARED must reuse shared product, production, producer and named buyer-demand records, retaining their source, units, period and place.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR088, body after heading at paragraph 1047
Source passage: SHARED must reuse shared product, production, producer and named buyer-demand records, retaining their source, units, period and place.
Need: Proposed need: Connect products producers and buyers. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed institutional service/knowledge owner and publication reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C05; C09
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR089 · Keep livelihood outcomes separate
SHARED must record the definition, period, evidence and denominator for each employment, income, training, women/youth participation or other outcome. A population count is not programme participation.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR089, body after heading at paragraph 1050
Source passage: SHARED must record the definition, period, evidence and denominator for each employment, income, training, women/youth participation or other outcome. A population count is not programme participation.
Need: Proposed need: Keep livelihood outcomes separate. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed institutional service/knowledge owner and publication reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C05; C09
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR129 · Catalogue documents and media
SHARED must keep evidence descriptive information, checksum, classification, version and review/publication state with controlled project, domain and location links.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR129, body after heading at paragraph 1053
Source passage: SHARED must keep evidence descriptive information, checksum, classification, version and review/publication state with controlled project, domain and location links.
Need: Proposed need: Catalogue documents and media. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed institutional service/knowledge owner and publication reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C05; C09
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR130 · Protect originals and derived files
SHARED must store originals that cannot be changed and controlled previews outside public web folders. Replacement must create a new version.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR130, body after heading at paragraph 1056
Source passage: SHARED must store originals that cannot be changed and controlled previews outside public web folders. Replacement must create a new version.
Need: Proposed need: Protect originals and derived files. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed institutional service/knowledge owner and publication reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C05; C09
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR131 · Scan and authorize file use
SHARED must enforce size, type, signature, renamed storage, quarantine and genuine malware checks before publication. Reauthorize preview, download and export; expire temporary links where relevant.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR131, body after heading at paragraph 1059
Source passage: SHARED must enforce size, type, signature, renamed storage, quarantine and genuine malware checks before publication. Reauthorize preview, download and export; expire temporary links where relevant.
Need: Proposed need: Scan and authorize file use. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed institutional service/knowledge owner and publication reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C05; C09
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR132 · Review knowledge publication
SHARED must enforce knowledge authoring, independent review, publication, replacement by a newer version, retention and archive stages. Keep earlier versions unchanged.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR132, body after heading at paragraph 1062
Source passage: SHARED must enforce knowledge authoring, independent review, publication, replacement by a newer version, retention and archive stages. Keep earlier versions unchanged.
Need: Proposed need: Review knowledge publication. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed institutional service/knowledge owner and publication reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C05; C09
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR133 · Retain eligible citations
SHARED must link knowledge to permitted projects, areas, sources, evidence, results, decisions and deliverables. Recheck restricted or withdrawn citations without leaking descriptive information.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR133, body after heading at paragraph 1065
Source passage: SHARED must link knowledge to permitted projects, areas, sources, evidence, results, decisions and deliverables. Recheck restricted or withdrawn citations without leaking descriptive information.
Need: Proposed need: Retain eligible citations. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed institutional service/knowledge owner and publication reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C05; C09
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR134 · Offer a simple beneficiary view
SHARED must let public readers find eligible local information, options, opportunities and project activities without an account. Signed-in readers must retain an uncomplicated public view.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR134, body after heading at paragraph 1068
Source passage: SHARED must let public readers find eligible local information, options, opportunities and project activities without an account. Signed-in readers must retain an uncomplicated public view.
Need: Proposed need: Offer a simple beneficiary view. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed institutional service/knowledge owner and publication reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C05; C09
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR135 · Keep anonymous intake closed until approved
SHARED must keep protected feedback separate from public grievances. Public activation needs a recorded policy covering receiver, deadlines, independent appeal, privacy, safeguarding and abuse controls.
Source class: Documented consultation input
Evidence locator: SRS Version 1.5, FR135, body after heading at paragraph 1071
Source passage: SHARED must keep protected feedback separate from public grievances. Public activation needs a recorded policy covering receiver, deadlines, independent appeal, privacy, safeguarding and abuse controls.
Need: Proposed need: Keep anonymous intake closed until approved. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed institutional service/knowledge owner and publication reviewer; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C02; C05; C09
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR082 · Keep harvest and sale evidence
SHARED must retain product, quantity, unit, dates, currency, source and scope for harvest batches, buyers, sales and recorded sale-payment evidence. Recording evidence is not executing a payment.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR082, body after heading at paragraph 1107
Source passage: SHARED must retain product, quantity, unit, dates, currency, source and scope for harvest batches, buyers, sales and recorded sale-payment evidence. Recording evidence is not executing a payment.
Need: Proposed need: Keep harvest and sale evidence. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed sector/programme data owner and method specialist; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C02; C04; E01; E02
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR083 · Keep origin and currency explicit
SHARED must retain a source-supported origin assertion for the particular record and expire the assertion when the supporting facts change. Complete unknown currency through authorized evidence without changing amounts or an established currency silently.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR083, body after heading at paragraph 1110
Source passage: SHARED must retain a source-supported origin assertion for the particular record and expire the assertion when the supporting facts change. Complete unknown currency through authorized evidence without changing amounts or an established currency silently.
Need: Proposed need: Keep origin and currency explicit. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed sector/programme data owner and method specialist; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C02; C04; E01; E02
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR084 · Compare only compatible market evidence
SHARED must retain exact product, unit, origin, periods, row versions and comparison time when comparing production and demand. Different periods must not produce a misleading quantity difference.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR084, body after heading at paragraph 1113
Source passage: SHARED must retain exact product, unit, origin, periods, row versions and comparison time when comparing production and demand. Different periods must not produce a misleading quantity difference.
Need: Proposed need: Compare only compatible market evidence. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed sector/programme data owner and method specialist; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C02; C04; E01; E02
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR085 · Use accepted seasonal arithmetic
SHARED must use reviewed formula versions and exact compatible inputs for seasonal production, cost, revenue, margin and break-even outputs. Unknown costs, yield assumptions, currencies and season definitions must block the affected result or appear as explicitly incomplete.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR085, body after heading at paragraph 1116
Source passage: SHARED must use reviewed formula versions and exact compatible inputs for seasonal production, cost, revenue, margin and break-even outputs. Unknown costs, yield assumptions, currencies and season definitions must block the affected result or appear as explicitly incomplete.
Need: Proposed need: Use accepted seasonal arithmetic. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed sector/programme data owner and method specialist; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C02; C04; E01; E02
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR092 · Keep PES frameworks controlled
SHARED must retain the owner and authority of PES schemes, agreements, service verification and source-reported payment-stage evidence. Missing rates, eligibility, appeals or legal approval must not be invented.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR092, body after heading at paragraph 1119
Source passage: SHARED must retain the owner and authority of PES schemes, agreements, service verification and source-reported payment-stage evidence. Missing rates, eligibility, appeals or legal approval must not be invented.
Need: Proposed need: Keep PES frameworks controlled. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: Appointed sector/programme data owner and method specialist; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C02; C04; E03
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR093 · Trace programme connections
SHARED must connect permitted support, product, asset, market, outcome and evidence records in analysis while preserving source versions and original scope.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR093, body after heading at paragraph 1122
Source passage: SHARED must connect permitted support, product, asset, market, outcome and evidence records in analysis while preserving source versions and original scope.
Need: Proposed need: Trace programme connections. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: Appointed sector/programme data owner and method specialist; named authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP3
Proposed release: Proposed first release via WP3
Accepted release: Not decided
Decision references: C01; C11; C02; C04; E03
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR136 · Use the API for all web actions
SHARED must provide a web application that uses the published service contracts, secure server-side sessions, anti-forgery protection and secure cookies. It must never access database tables directly.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR136, body after heading at paragraph 1177
Source passage: SHARED must provide a web application that uses the published service contracts, secure server-side sessions, anti-forgery protection and secure cookies. It must never access database tables directly.
Need: Proposed need: Use the API for all web actions. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C07; C08; C06
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR137 · Keep workflows simple and accessible
SHARED must use guided steps, searchable choices, progressive details and clear loading, empty, error and denied states. Validate responsive, keyboard and accessibility behaviour on the agreed matrix.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR137, body after heading at paragraph 1180
Source passage: SHARED must use guided steps, searchable choices, progressive details and clear loading, empty, error and denied states. Validate responsive, keyboard and accessibility behaviour on the agreed matrix.
Need: Proposed need: Keep workflows simple and accessible. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C07; C08; C06
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR138 · Use approved choices and language resources
SHARED must obtain approved choices from authorised API reference data. It must support English, Sinhala and Tamil resources for the agreed delivery scope. Client-appointed reviewers must accept terminology and translations before release.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR138, body after heading at paragraph 1183
Source passage: SHARED must obtain approved choices from authorised API reference data. It must support English, Sinhala and Tamil resources for the agreed delivery scope. Client-appointed reviewers must accept terminology and translations before release.
Need: Proposed need: Use approved choices and language resources. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C07; C08; C06
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR139 · Protect sign in across approved access channels
SHARED must use environment-safe configuration and the same authenticated service interfaces across approved access channels. Each channel must protect credentials and session material using approved secure facilities and enforce rotation, revocation, expiry and logout. An additional field-access channel is a proposed option under C01, C06 and C07, not an accepted first-release commitment.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR139, body after heading at paragraph 1186; correction request IR-007/IR-001 and Version 1.6 FR139
Source passage: SHARED must use environment-safe configuration and the same authenticated API in mobile builds. Store secrets in operating-system secure storage and support token rotation, revocation, expiry and logout.
Need: Proposed need: Protect mobile sign in. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C07; C08; C06
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR140 · Capture permitted field evidence
Through the responsive core interface, SHARED must allow permitted users to browse assigned projects, domains, places and maps and capture authorised location, source, accuracy, observation time and evidence. An additional field-access channel or local draft-storage capability is conditional on C01, C06 and C07. When local drafts are permitted, protect them under the approved encryption, retention and privacy rules.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR140, body after heading at paragraph 1189; correction request IR-007/IR-001 and Version 1.6 FR140
Source passage: SHARED must allow permitted users to browse assigned projects, domains, places and maps and capture authorized location, source, accuracy, time and evidence. Drafts must be encrypted and privacy-aware.
Need: Proposed need: Capture permitted field evidence. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C07; C08; C06
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR141 · Control optional offline submission
If offline operation is selected under C01, C06 and C07, SHARED must protect downloaded authorised assignments, local drafts and evidence under the agreed retention and privacy rules. Show pending, sending, received, rejected and conflict states. Synchronise through the common authenticated service interfaces using stable retry identifiers. Offline operation remains a proposed option until the client accepts its scope.
Source class: Externally conditional option
Evidence locator: SRS Version 1.5, FR141, body after heading at paragraph 1192; correction request IR-007/IR-001 and Version 1.6 FR141
Source passage: SHARED must support encrypted mobile offline drafts and evidence capture for downloaded authorized field assignments.
Need: Proposed need: Show the sending status of offline records. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C07; C08; C06
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR142 · Explain the architecture through real workflows
SHARED must retain a clear system explanation and role-based user guidance linked to the relevant permitted workflow. The prototype presentation and diagrams support this explanation. A demonstration link does not grant access or establish operational acceptance.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR142, body after heading at paragraph 1195
Source passage: SHARED must retain a clear system explanation and role-based user guidance linked to the relevant permitted workflow. The prototype presentation and diagrams support this explanation. A demonstration link does not grant access or establish operational acceptance.
Need: Proposed need: Explain the architecture through real workflows. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR143 · Expose controlled API contracts
SHARED must use versioned API routes and explicit request/response contracts with an accurate API description. Reject unsupported request properties.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR143, body after heading at paragraph 1198
Source passage: SHARED must use versioned API routes and explicit request/response contracts with an accurate API description. Reject unsupported request properties.
Need: Proposed need: Expose controlled API contracts. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR144 · Bound work and return safe errors
SHARED must return consistent safe errors without internal database commands, stack traces or secrets. Lists must use deterministic paging, limits, cancellation and timeouts.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR144, body after heading at paragraph 1201
Source passage: SHARED must return consistent safe errors without internal database commands, stack traces or secrets. Lists must use deterministic paging, limits, cancellation and timeouts.
Need: Proposed need: Bound work and return safe errors. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR145 · Prevent duplicate requests and conflicting edits
Use request references, expected-version checks and stable retry identifiers. Limit retries so repeated failures do not overload the service. Health checks must use approved service operations.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR145, body after heading at paragraph 1204
Source passage: Use request references, expected-version checks and stable retry identifiers. Limit retries so repeated failures do not overload the service. Health checks must use approved service operations.
Need: Proposed need: Prevent duplicate requests and conflicting edits. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR146 · Protect transport and endpoints
SHARED must use HTTPS, secure headers, approved origins, rate limits, input checks and endpoint plus permission checks for the requested record.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR146, body after heading at paragraph 1207
Source passage: SHARED must use HTTPS, secure headers, approved origins, rate limits, input checks and endpoint plus permission checks for the requested record.
Need: Proposed need: Protect transport and endpoints. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR155 · Separate interface and hosting responsibilities
SHARED must keep user-interface responsibilities separate from authenticated application services, shared business rules and controlled data access. Clients must not access data-store tables directly. Protect configuration, files and process permissions. A separate deployment or hosting topology is a proposed option under C07; select it only after reviewing isolation, operations, recovery, cost and portability.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR155, body after heading at paragraph 1210; correction request IR-007/IR-001 and Version 1.6 FR155
Source passage: SHARED must deploy the web application and shared service interface as separate applications. Keep authentication and database operations in the shared services, protect process settings and storage, restrict origins and approve background processing mechanisms.
Need: Proposed need: Separate web and shared service hosting responsibilities. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP4
Proposed release: Proposed first release via WP4
Accepted release: Not decided
Decision references: C01; C11; C07; C08; C06
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR147 · Use approved operations to access data
SHARED must perform runtime data access through a controlled server-side data access layer and approved operations, including identity and health checks. Runtime principals receive only the necessary permissions. Clients never access database tables. The selected database plan must specify the operation catalogue and enforcement evidence.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR147, body after heading at paragraph 1316
Source passage: SHARED must perform runtime data access through a controlled server-side data access layer and approved operations, including identity and health checks. Runtime principals receive only the necessary permissions. Clients never access database tables. The selected database plan must specify the operation catalogue and enforcement evidence.
Need: Proposed need: Use approved operations to access data. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR148 · Keep action history and source links
SHARED must record significant actor, action, resource, scope, result, reason, standard time and request reference. Trace published data back through source, validation and review.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR148, body after heading at paragraph 1319
Source passage: SHARED must record significant actor, action, resource, scope, result, reason, standard time and request reference. Trace published data back through source, validation and review.
Need: Proposed need: Keep action history and source links. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR01 · Availability
The service shall achieve at least 99 percent availability. This is the TOR minimum. Proposed measurement is a calendar month of agreed service minutes, including planned maintenance until an exclusion policy is approved.
Source class: Direct terms-of-reference obligation
Evidence locator: SRS Version 1.5, NFR01, body after heading at paragraph 1324
Source passage: The service shall achieve at least 99 percent availability. This is the TOR minimum. Proposed measurement is a calendar month of agreed service minutes, including planned maintenance until an exclusion policy is approved.
Need: Proposed need: Availability. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR02 · Interactive performance
Proposed target: 100 concurrent authenticated users; standard bounded API reads p95 at most 750 ms and p99 at most 1.5 seconds; error rate below 0.5 percent.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, NFR02, body after heading at paragraph 1328
Source passage: Proposed target: 100 concurrent authenticated users; standard bounded API reads p95 at most 750 ms and p99 at most 1.5 seconds; error rate below 0.5 percent.
Need: Proposed need: Interactive performance. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR03 · Spatial performance
Proposed target: bounded spatial queries p95 at most 2 seconds and p99 at most 4 seconds.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, NFR03, body after heading at paragraph 1332
Source passage: Proposed target: bounded spatial queries p95 at most 2 seconds and p99 at most 4 seconds.
Need: Proposed need: Spatial performance. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C03; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR04 · Capacity and scaling
Proposed sizing: 250 organisations and one million vector features at the agreed workload. Test twice the interactive load for controlled saturation.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, NFR04, body after heading at paragraph 1336
Source passage: Proposed sizing: 250 organisations and one million vector features at the agreed workload. Test twice the interactive load for controlled saturation.
Need: Proposed need: Capacity and scaling. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR05 · Low bandwidth and responsive use
Proposed profile: 1.5 Mbps down, 750 Kbps up, 300 ms round trip and 1 percent packet loss. Essential initial transfer at most 1.5 MiB compressed. The system shall support mobile-compatible use of the agreed core journeys on client-agreed devices.
Source class: Direct terms-of-reference obligation
Evidence locator: SRS Version 1.5, NFR05, body after heading at paragraph 1340
Source passage: Proposed profile: 1.5 Mbps down, 750 Kbps up, 300 ms round trip and 1 percent packet loss. Essential initial transfer at most 1.5 MiB compressed. The system shall support mobile-compatible use of the agreed core journeys on client-agreed devices.
Need: Proposed need: Low bandwidth and responsive use. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C06; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR06 · Accessibility and language
Proposed web target is WCAG 2.2 AA. Provide keyboard operation, visible focus, labelled controls, readable error messages, text alternatives, accessible tables and text scaling. English, Sinhala and Tamil coverage requires client agreement.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, NFR06, body after heading at paragraph 1344
Source passage: Proposed web target is WCAG 2.2 AA. Provide keyboard operation, visible focus, labelled controls, readable error messages, text alternatives, accessible tables and text scaling. English, Sinhala and Tamil coverage requires client agreement.
Need: Proposed need: Accessibility and language. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C06
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR07 · Security verification
Use threat modelling and an agreed OWASP ASVS control set, proposed Level 2. Protect sessions, inputs, files, exports, transport and secrets.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, NFR07, body after heading at paragraph 1348
Source passage: Use threat modelling and an agreed OWASP ASVS control set, proposed Level 2. Protect sessions, inputs, files, exports, transport and secrets.
Need: Proposed need: Security verification. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C05; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR08 · Data protection
Collect only information needed for an approved purpose. Apply classification, disclosure limits, retention and rights handling to originals, results, exports and backups.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, NFR08, body after heading at paragraph 1352
Source passage: Collect only information needed for an approved purpose. Apply classification, disclosure limits, retention and rights handling to originals, results, exports and backups.
Need: Proposed need: Data protection. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C04; C05
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR09 · Recovery
Proposed recovery point objective is 24 hours and recovery time objective is 8 hours. Include database, protected files, configuration, keys and spatial resources.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, NFR09, body after heading at paragraph 1356
Source passage: Proposed recovery point objective is 24 hours and recovery time objective is 8 hours. Include database, protected files, configuration, keys and spatial resources.
Need: Proposed need: Recovery. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR10 · Reliability
Commands shall use expected versions and safe retry references. Save a business change and its delivery request reliably together.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, NFR10, body after heading at paragraph 1360
Source passage: Commands shall use expected versions and safe retry references. Save a business change and its delivery request reliably together.
Need: Proposed need: Reliability. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR11 · Interoperability
Publish versioned API and data contracts. Declare supported geospatial protocols, encodings, units, coordinate systems and export formats.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, NFR11, body after heading at paragraph 1364
Source passage: Publish versioned API and data contracts. Declare supported geospatial protocols, encodings, units, coordinate systems and export formats.
Need: Proposed need: Interoperability. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C04; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR12 · Maintainability and portability
Keep business definitions configurable, modules separated and dependencies supported. Supply reproducible builds, migrations, operation contracts and complete export.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, NFR12, body after heading at paragraph 1368
Source passage: Keep business definitions configurable, modules separated and dependencies supported. Supply reproducible builds, migrations, operation contracts and complete export.
Need: Proposed need: Maintainability and portability. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR13 · Audit and observability
Retain protected business audit separately from redacted diagnostics. Proposed correlation target is at least 99 percent of API requests; significant events queryable within five minutes.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, NFR13, body after heading at paragraph 1372
Source passage: Retain protected business audit separately from redacted diagnostics. Proposed correlation target is at least 99 percent of API requests; significant events queryable within five minutes.
Need: Proposed need: Audit and observability. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C05; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
NFR14 · Support and sustainability
Name the service owner, support levels, escalation, funding, renewal obligations and patch responsibility before operational acceptance.
Source class: Documented consultation input
Evidence locator: SRS Version 1.5, NFR14, body after heading at paragraph 1376
Source passage: Name the service owner, support levels, escalation, funding, renewal obligations and patch responsibility before operational acceptance.
Need: Proposed need: Support and sustainability. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP1
Proposed release: Proposed first release via WP1
Accepted release: Not decided
Decision references: C01; C11; C07
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR149 · Protect discovery and notification delivery
SHARED must protect private people and sensitive locations from disclosure through search, counts and exports. If an action creates a notification, save the action and delivery request reliably together. Retry delivery without duplicating the message.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR149, body after heading at paragraph 1385
Source passage: SHARED must protect private people and sensitive locations from disclosure through search, counts and exports. If an action creates a notification, save the action and delivery request reliably together. Retry delivery without duplicating the message.
Need: Proposed need: Protect discovery and notification delivery. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP5
Proposed release: Proposed first release via WP5
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR151 · Separate environments and secrets
SHARED must separate development, test, staging and production configuration and inject secrets through protected settings. Do not publish credentials or private data in code, documents, logs or exports.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR151, body after heading at paragraph 1388
Source passage: SHARED must separate development, test, staging and production configuration and inject secrets through protected settings. Do not publish credentials or private data in code, documents, logs or exports.
Need: Proposed need: Separate environments and secrets. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP5
Proposed release: Proposed first release via WP5
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR152 · Monitor service health without exposing private data
SHARED must monitor service availability, failures and background processing. Retain safe diagnostic details and a request reference so an authorised operator can investigate an error. Health responses and logs must not expose credentials, personal records or original source content.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR152, body after heading at paragraph 1391
Source passage: SHARED must monitor service availability, failures and background processing. Retain safe diagnostic details and a request reference so an authorised operator can investigate an error. Health responses and logs must not expose credentials, personal records or original source content.
Need: Proposed need: Monitor service health without exposing private data. Confirm purpose, priority and output with the proposed owner.
Need evidence: Individual accepted institutional need not located; authored refinement linked to the TOR capability only
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP5
Proposed release: Proposed first release via WP5
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR153 · Release through controlled runbooks
SHARED must support reviewed procedures for deployment, migration, rollback or forward repair, credential rotation, incidents and continuity. Do not upgrade the database at application startup.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR153, body after heading at paragraph 1394
Source passage: SHARED must support reviewed procedures for deployment, migration, rollback or forward repair, credential rotation, incidents and continuity. Do not upgrade the database at application startup.
Need: Proposed need: Release through controlled runbooks. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP5
Proposed release: Proposed first release via WP5
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR154 · Prove coordinated recovery
SHARED must back up the database and protected files under agreed security and retention rules. Confirm recovery targets through an authorized restore exercise, not backup creation alone.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR154, body after heading at paragraph 1397
Source passage: SHARED must back up the database and protected files under agreed security and retention rules. Confirm recovery targets through an authorized restore exercise, not backup creation alone.
Need: Proposed need: Prove coordinated recovery. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP5
Proposed release: Proposed first release via WP5
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Technical only
Implementation: Future service specified
Verification: Clause cases defined; execution is recorded separately
FR150 · Govern change and trace requirements
SHARED must keep business settings editable and dated. Register proposed products before claiming delivery. Link requirements to design, work, implementation, tests and evidence, with controlled change history.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR150, body after heading at paragraph 1524
Source passage: SHARED must keep business settings editable and dated. Register proposed products before claiming delivery. Link requirements to design, work, implementation, tests and evidence, with controlled change history.
Need: Proposed need: Govern change and trace requirements. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP5
Proposed release: Proposed first release via WP5
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
FR156 · List software gaps and missing external decisions separately
SHARED must track unfinished software separately from missing data, expert decisions and governance approval.
Source class: Author-proposed refinement
Evidence locator: SRS Version 1.5, FR156, body after heading at paragraph 1527
Source passage: SHARED must track unfinished software separately from missing data, expert decisions and governance approval.
Need: Proposed need: List software gaps and missing external decisions separately. Confirm purpose, priority and output with the proposed owner.
Need evidence: Documented functional input, not institutional acceptance
Proposed owner: PMU product owner and appointed technical/service owners; named acceptance authority pending
Appointed owner: Not appointed in available evidence
Owner status: Proposed owner; appointment and mandate pending C02
Work package: WP5
Proposed release: Proposed first release via WP5
Accepted release: Not decided
Decision references: C01; C11; C07; C08
Validation status: Source and clause mapping prepared; institutional validation pending
Retained design coverage: Design shown
Implementation: Mock design mapped; not operational implementation
Verification: Clause cases defined; execution is recorded separately
Current publication controls
The 34 forms retain 280 baseline fields. Three explicit publication controls bring the current total to 283. Their types describe the prototype inputs and do not approve institutional data definitions or grant source rights.
knowledge.audience
Id: knowledge.audience
Form key: knowledge
Form label: Knowledge library
Key: audience
Label: Permitted audience
Prototype control type: select
Options: Not confirmed; Institution; Public
Required: False
Configured default: No explicit field default is declared
New record initial value: Not confirmed
Default basis: demoEditor passes an empty new-record value to demoFieldInput. A select displays its first option; the text input starts empty.
Source file: candidate/index.html
Source locator: DEMO_KINDS.knowledge.fields / demoField('audience',...)
Source definition: demoField('audience','Permitted audience','select',{options:['Not confirmed','Institution','Public'],required:false})
Source digest: 11961088799768e0bc949324c8b3f2d3a31ee869f3715df21178c1882077aab0
Inventory evidence: evidence/tests/inventory/field-counts.json
Change scope: Added prototype publication control; no new requirement or acceptance case
Dictionary status: Prototype control type only; no institutional data type, unit or dictionary approval inferred
Proposed owner: Institution data custodian and competent domain/source reviewer; roles proposed only
Appointed owner: Not confirmed
Decision references: C04; E01
Institutional decision status: Pending in Institution review only
knowledge.publicUse
Id: knowledge.publicUse
Form key: knowledge
Form label: Knowledge library
Key: publicUse
Label: Prototype public-use permission
Prototype control type: select
Options: Not confirmed; Permitted in demo; Not permitted
Required: False
Configured default: No explicit field default is declared
New record initial value: Not confirmed
Default basis: demoEditor passes an empty new-record value to demoFieldInput. A select displays its first option; the text input starts empty.
Source file: candidate/index.html
Source locator: DEMO_KINDS.knowledge.fields / demoField('publicUse',...)
Source definition: demoField('publicUse','Prototype public-use permission','select',{options:['Not confirmed','Permitted in demo','Not permitted'],required:false})
Source digest: 11961088799768e0bc949324c8b3f2d3a31ee869f3715df21178c1882077aab0
Inventory evidence: evidence/tests/inventory/field-counts.json
Change scope: Added prototype publication control; no new requirement or acceptance case
Dictionary status: Prototype control type only; no institutional data type, unit or dictionary approval inferred
Proposed owner: Institution data custodian and competent domain/source reviewer; roles proposed only
Appointed owner: Not confirmed
Decision references: C04; E01
Institutional decision status: Pending in Institution review only
knowledge.permittedVersions
Id: knowledge.permittedVersions
Form key: knowledge
Form label: Knowledge library
Key: permittedVersions
Label: Earlier source versions still permitted (comma-separated)
Prototype control type: text
Options:
Required: False
Configured default: No explicit field default is declared
New record initial value:
Default basis: demoEditor passes an empty new-record value to demoFieldInput. A select displays its first option; the text input starts empty.
Source file: candidate/index.html
Source locator: DEMO_KINDS.knowledge.fields / demoField('permittedVersions',...)
Source definition: demoField('permittedVersions','Earlier source versions still permitted (comma-separated)','text',{required:false})
Source digest: 11961088799768e0bc949324c8b3f2d3a31ee869f3715df21178c1882077aab0
Inventory evidence: evidence/tests/inventory/field-counts.json
Change scope: Added prototype publication control; no new requirement or acceptance case
Dictionary status: Prototype control type only; no institutional data type, unit or dictionary approval inferred
Proposed owner: Institution data custodian and competent domain/source reviewer; roles proposed only
Appointed owner: Not confirmed
Decision references: C04; E01
Institutional decision status: Pending in Institution review only
Clauses and test cases
470 focused clauses and 637 case definitions. Shared suites cover common permissions and output paths. Future service cases remain not executed. Separate prototype design checks do not prove secure authentication, storage, availability or live integrations.
FR029-C01 · Keep source ownership in the shared source/dataset catalogue.
Parent requirement and conditions: SHARED must keep source ownership, custody, licence, update frequency, coverage, quality, classification, dataset versions and available distributions in the shared catalogue.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR029-C01-A01, FR029-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR029-C02 · Keep custody in the shared source/dataset catalogue.
Parent requirement and conditions: SHARED must keep source ownership, custody, licence, update frequency, coverage, quality, classification, dataset versions and available distributions in the shared catalogue.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR029-C02-A01, FR029-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR029-C03 · Keep licence in the shared source/dataset catalogue.
Parent requirement and conditions: SHARED must keep source ownership, custody, licence, update frequency, coverage, quality, classification, dataset versions and available distributions in the shared catalogue.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR029-C03-A01, FR029-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR029-C04 · Keep update frequency in the shared source/dataset catalogue.
Parent requirement and conditions: SHARED must keep source ownership, custody, licence, update frequency, coverage, quality, classification, dataset versions and available distributions in the shared catalogue.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR029-C04-A01, FR029-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR029-C05 · Keep coverage in the shared source/dataset catalogue.
Parent requirement and conditions: SHARED must keep source ownership, custody, licence, update frequency, coverage, quality, classification, dataset versions and available distributions in the shared catalogue.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR029-C05-A01, FR029-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR029-C06 · Keep quality in the shared source/dataset catalogue.
Parent requirement and conditions: SHARED must keep source ownership, custody, licence, update frequency, coverage, quality, classification, dataset versions and available distributions in the shared catalogue.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR029-C06-A01, FR029-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR029-C07 · Keep classification in the shared source/dataset catalogue.
Parent requirement and conditions: SHARED must keep source ownership, custody, licence, update frequency, coverage, quality, classification, dataset versions and available distributions in the shared catalogue.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR029-C07-A01, FR029-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR029-C08 · Keep dataset versions in the shared source/dataset catalogue.
Parent requirement and conditions: SHARED must keep source ownership, custody, licence, update frequency, coverage, quality, classification, dataset versions and available distributions in the shared catalogue.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR029-C08-A01, FR029-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR029-C09 · Keep available distributions in the shared source/dataset catalogue.
Parent requirement and conditions: SHARED must keep source ownership, custody, licence, update frequency, coverage, quality, classification, dataset versions and available distributions in the shared catalogue.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR029-C09-A01, FR029-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR030-C01 · SHARED must expose each dataset version's field definitions, types, units and supported integration method.
Parent requirement and conditions: SHARED must expose each dataset version's field definitions, types, units and supported integration method.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR030-C01-A01, FR030-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR031-C01 · SHARED must record each indicator definition's unit, owner, frequency, disaggregation, baseline and target descriptive information, and required sources.
Parent requirement and conditions: SHARED must record each indicator definition's unit, owner, frequency, disaggregation, baseline and target descriptive information, and required sources. Observations require approved contracts.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR031-C01-A01, FR031-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR031-C02 · Observations require approved contracts.
Parent requirement and conditions: SHARED must record each indicator definition's unit, owner, frequency, disaggregation, baseline and target descriptive information, and required sources. Observations require approved contracts.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR031-C02-A01, FR031-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR032-C01 · SHARED must keep unchanged or versioned staged input, then use the approved defined data structures for accepted records.
Parent requirement and conditions: SHARED must keep unchanged or versioned staged input, then use the approved defined data structures for accepted records. Do not create a single store of values without defined types and meanings.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR032-C01-A01, FR032-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR032-C02 · Do not create a single store of values without defined types and meanings.
Parent requirement and conditions: SHARED must keep unchanged or versioned staged input, then use the approved defined data structures for accepted records. Do not create a single store of values without defined types and meanings.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR032-C02-A01, FR032-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR033-C01 · SHARED must use shared assigned work, responses, evidence and review for dataset requests and quality feedback.
Parent requirement and conditions: SHARED must use shared assigned work, responses, evidence and review for dataset requests and quality feedback. Show permitted usage relationships without claiming complete view/download telemetry.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR033-C01-A01, FR033-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR033-C02 · Show permitted usage relationships without claiming complete view/download telemetry.
Parent requirement and conditions: SHARED must use shared assigned work, responses, evidence and review for dataset requests and quality feedback. Show permitted usage relationships without claiming complete view/download telemetry.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR033-C02-A01, FR033-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR034-C01 · SHARED must retain reviewed links from domain fields to dataset fields that identify the shared field and version, permitted area and period, and actual source availability.
Parent requirement and conditions: SHARED must retain reviewed links from domain fields to dataset fields that identify the shared field and version, permitted area and period, and actual source availability. A field link must not copy values or approve observations.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR034-C01-A01, FR034-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR034-C02 · A field link must not copy values or approve observations.
Parent requirement and conditions: SHARED must retain reviewed links from domain fields to dataset fields that identify the shared field and version, permitted area and period, and actual source availability. A field link must not copy values or approve observations.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR034-C02-A01, FR034-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR035-C01 · SHARED must require external contributors to use authenticated web, mobile or API workflows.
Parent requirement and conditions: SHARED must require external contributors to use authenticated web, mobile or API workflows. They must not read or write database tables directly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR035-C01-A01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR035-C02 · They must not read or write database tables directly.
Parent requirement and conditions: SHARED must require external contributors to use authenticated web, mobile or API workflows. They must not read or write database tables directly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR035-C02-A01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR036-C01 · SHARED must enforce the configured workflow for draft, submission, validation, review, return, approval, publication and archive steps.
Parent requirement and conditions: SHARED must enforce the configured workflow for draft, submission, validation, review, return, approval, publication and archive steps. Invalid transitions must fail atomically.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR036-C01-A01, FR036-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION, SC-INTERFACE-BAD
FR036-C02 · Invalid transitions must fail atomically.
Parent requirement and conditions: SHARED must enforce the configured workflow for draft, submission, validation, review, return, approval, publication and archive steps. Invalid transitions must fail atomically.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR036-C02-A01, FR036-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION, SC-INTERFACE-BAD
FR037-C01 · SHARED must retain source, submitter, organization, time, reporting period, schema version, rights, owner, sensitivity and validation outcomes as unchanged or versioned evidence.
Parent requirement and conditions: SHARED must retain source, submitter, organization, time, reporting period, schema version, rights, owner, sensitivity and validation outcomes as unchanged or versioned evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR037-C01-A01, FR037-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR038-C01 · SHARED must store the supplied source resources, source rows and measured location accuracy with the shared observation.
Parent requirement and conditions: SHARED must store the supplied source resources, source rows and measured location accuracy with the shared observation. Reject unsupported precision, overflow and excessive text instead of silently changing it.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR038-C01-A01, FR038-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
FR038-C02 · Reject unsupported precision, overflow and excessive text instead of silently changing it.
Parent requirement and conditions: SHARED must store the supplied source resources, source rows and measured location accuracy with the shared observation. Reject unsupported precision, overflow and excessive text instead of silently changing it.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR038-C02-A01, FR038-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
FR039-C01 · SHARED must use configured field types and checks.
Parent requirement and conditions: SHARED must use configured field types and checks. Missing values, zero and false must remain different. Unknown observation time and GN must not be guessed.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR039-C01-A01, FR039-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR039-C02 · Missing values, zero and false must remain different.
Parent requirement and conditions: SHARED must use configured field types and checks. Missing values, zero and false must remain different. Unknown observation time and GN must not be guessed.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR039-C02-A01, FR039-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR039-C03 · Unknown observation time and GN must not be guessed.
Parent requirement and conditions: SHARED must use configured field types and checks. Missing values, zero and false must remain different. Unknown observation time and GN must not be guessed.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR039-C03-A01, FR039-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR040-C01 · SHARED must reuse published forms for surveys, trials, training and field feedback.
Parent requirement and conditions: SHARED must reuse published forms for surveys, trials, training and field feedback. When a form value is used in a report field, keep the approved mapping and the link back to the submitted evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR040-C01-A01, FR040-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR040-C02 · When a form value is used in a report field, keep the approved mapping and the link back to the submitted evidence.
Parent requirement and conditions: SHARED must reuse published forms for surveys, trials, training and field feedback. When a form value is used in a report field, keep the approved mapping and the link back to the submitted evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR040-C02-A01, FR040-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR041-C01 · SHARED must process every structured dataset import, including project and deliverable onboarding, through a published CSV, Excel, JSON or restricted XML contract, a quarantined original, row validation and a preview.
Parent requirement and conditions: SHARED must process every structured dataset import, including project and deliverable onboarding, through a published CSV, Excel, JSON or restricted XML contract, a quarantined original, row validation and a preview.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR041-C01-A01, FR041-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR042-C01 · SHARED must bind independent import approval to the exact list of included rows and target schema.
Parent requirement and conditions: SHARED must bind independent import approval to the exact list of included rows and target schema.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR042-C01-A01, FR042-D01, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR043-C01 · SHARED must retain auditable batches, rows, validation decisions, source evidence and corrective follow-up, protected by their access scope.
Parent requirement and conditions: SHARED must retain auditable batches, rows, validation decisions, source evidence and corrective follow-up, protected by their access scope.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR043-C01-A01, FR043-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR044-C01 · SHARED must keep the same identifier when an upload or command is retried.
Parent requirement and conditions: SHARED must keep the same identifier when an upload or command is retried. If the response is lost, retain the protected original and check the saved outcome before trying again. Never change the earlier evidence to make the retry appear successful.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR044-C01-A01, FR044-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR044-C02 · If the response is lost, retain the protected original and check the saved outcome before trying again.
Parent requirement and conditions: SHARED must keep the same identifier when an upload or command is retried. If the response is lost, retain the protected original and check the saved outcome before trying again. Never change the earlier evidence to make the retry appear successful.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR044-C02-A01, FR044-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR044-C03 · Never change the earlier evidence to make the retry appear successful.
Parent requirement and conditions: SHARED must keep the same identifier when an upload or command is retried. If the response is lost, retain the protected original and check the saved outcome before trying again. Never change the earlier evidence to make the retry appear successful.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR044-C03-A01, FR044-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR045-C01 · SHARED must support CSV, XLSX, JSON arrays of scalar-valued records and restricted XML row documents through one versioned mapping and validation workflow.
Parent requirement and conditions: SHARED must support CSV, XLSX, JSON arrays of scalar-valued records and restricted XML row documents through one versioned mapping and validation workflow. Reject unsupported nesting and oversized content. Never execute spreadsheet formulas, macros, XML DTDs or external entities.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR045-C01-A01, FR045-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR045-C02 · Reject unsupported nesting and oversized content.
Parent requirement and conditions: SHARED must support CSV, XLSX, JSON arrays of scalar-valued records and restricted XML row documents through one versioned mapping and validation workflow. Reject unsupported nesting and oversized content. Never execute spreadsheet formulas, macros, XML DTDs or external entities.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR045-C02-A01, FR045-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR045-C03 · Never execute spreadsheet formulas, macros, XML DTDs or external entities.
Parent requirement and conditions: SHARED must support CSV, XLSX, JSON arrays of scalar-valued records and restricted XML row documents through one versioned mapping and validation workflow. Reject unsupported nesting and oversized content. Never execute spreadsheet formulas, macros, XML DTDs or external entities.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR045-C03-A01, FR045-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR046-C01 · SHARED must record original checksum, owner, classification and source purpose.
Parent requirement and conditions: SHARED must record original checksum, owner, classification and source purpose. Reuse matching sources only within compatible scope; requirements or guidance must not become observations automatically.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR046-C01-A01, FR046-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
FR046-C02 · Reuse matching sources only within compatible scope.
Parent requirement and conditions: SHARED must record original checksum, owner, classification and source purpose. Reuse matching sources only within compatible scope; requirements or guidance must not become observations automatically.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR046-C02-A01, FR046-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
FR046-C03 · requirements or guidance must not become observations automatically.
Parent requirement and conditions: SHARED must record original checksum, owner, classification and source purpose. Reuse matching sources only within compatible scope; requirements or guidance must not become observations automatically.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR046-C03-A01, FR046-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
FR047-C01 · SHARED must require approved provider configuration, processing permission and genuine clean scanning before document processing.
Parent requirement and conditions: SHARED must require approved provider configuration, processing permission and genuine clean scanning before document processing. Missing setup must be visible; never invent a scan or extraction result.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR047-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY
FR047-C02 · Missing setup must be visible.
Parent requirement and conditions: SHARED must require approved provider configuration, processing permission and genuine clean scanning before document processing. Missing setup must be visible; never invent a scan or extraction result.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR047-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY
FR047-C03 · never invent a scan or extraction result.
Parent requirement and conditions: SHARED must require approved provider configuration, processing permission and genuine clean scanning before document processing. Missing setup must be visible; never invent a scan or extraction result.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR047-C03-A01, SC-AUTH-ALLOW, SC-AUTH-DENY
FR048-C01 · SHARED must retain the original passage, table or page, uncertainty and processing record with each extraction suggestion.
Parent requirement and conditions: SHARED must retain the original passage, table or page, uncertainty and processing record with each extraction suggestion. Values must use allowed shared data types and destinations.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR048-C01-A01, FR048-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR048-C02 · Values must use allowed shared data types and destinations.
Parent requirement and conditions: SHARED must retain the original passage, table or page, uncertainty and processing record with each extraction suggestion. Values must use allowed shared data types and destinations.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR048-C02-A01, FR048-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR049-C01 · SHARED must require permitted users to verify every proposed base domain, subject, attribute and value.
Parent requirement and conditions: SHARED must require permitted users to verify every proposed base domain, subject, attribute and value. Route approved mappings through the relevant shared dataset batches and independent reviews.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR049-C01-A01, FR049-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH
FR049-C02 · Route approved mappings through the relevant shared dataset batches and independent reviews.
Parent requirement and conditions: SHARED must require permitted users to verify every proposed base domain, subject, attribute and value. Route approved mappings through the relevant shared dataset batches and independent reviews.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR049-C02-A01, FR049-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH
FR050-C01 · SHARED must record the mapping decision separately from the review of extracted values.
Parent requirement and conditions: SHARED must record the mapping decision separately from the review of extracted values. Keep rejected suggestions and corrections. Before saving, check permission and the current destination version again.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR050-C01-A01, FR050-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR050-C02 · Keep rejected suggestions and corrections.
Parent requirement and conditions: SHARED must record the mapping decision separately from the review of extracted values. Keep rejected suggestions and corrections. Before saving, check permission and the current destination version again.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR050-C02-A01, FR050-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR050-C03 · Before saving, check permission and the current destination version again.
Parent requirement and conditions: SHARED must record the mapping decision separately from the review of extracted values. Keep rejected suggestions and corrections. Before saving, check permission and the current destination version again.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR050-C03-A01, FR050-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR051-C01 · SHARED must bind each feed's source and dataset version to approved fields, keys, units, location context and origin designation.
Parent requirement and conditions: SHARED must bind each feed's source and dataset version to approved fields, keys, units, location context and origin designation. Disabled feeds cannot acquire or ingest new events. Configuration changes preserve history and invalidate affected approvals.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR051-C01-A01, FR051-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR051-C02 · Disabled feeds cannot acquire or ingest new events.
Parent requirement and conditions: SHARED must bind each feed's source and dataset version to approved fields, keys, units, location context and origin designation. Disabled feeds cannot acquire or ingest new events. Configuration changes preserve history and invalidate affected approvals.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR051-C02-A01, FR051-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR051-C03 · Configuration changes preserve history.
Parent requirement and conditions: SHARED must bind each feed's source and dataset version to approved fields, keys, units, location context and origin designation. Disabled feeds cannot acquire or ingest new events. Configuration changes preserve history and invalidate affected approvals.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR051-C03-A01, FR051-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR051-C04 · invalidate affected approvals.
Parent requirement and conditions: SHARED must bind each feed's source and dataset version to approved fields, keys, units, location context and origin designation. Disabled feeds cannot acquire or ingest new events. Configuration changes preserve history and invalidate affected approvals.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR051-C04-A01, FR051-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR052-C01 · SHARED must record source-event, observation-time, applicable device and value-field mappings for provider messages.
Parent requirement and conditions: SHARED must record source-event, observation-time, applicable device and value-field mappings for provider messages. An independent reviewer approves them; a mapping or governing-field change invalidates approval.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR052-C01-A01, FR052-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH
FR052-C02 · An independent reviewer approves them.
Parent requirement and conditions: SHARED must record source-event, observation-time, applicable device and value-field mappings for provider messages. An independent reviewer approves them; a mapping or governing-field change invalidates approval.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR052-C02-A01, FR052-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH
FR052-C03 · a mapping or governing-field change invalidates approval.
Parent requirement and conditions: SHARED must record source-event, observation-time, applicable device and value-field mappings for provider messages. An independent reviewer approves them; a mapping or governing-field change invalidates approval.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR052-C03-A01, FR052-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH
FR053-C01 · SHARED must provide adapters for institutional data services and device gateways using approved message contracts.
Parent requirement and conditions: SHARED must provide adapters for institutional data services and device gateways using approved message contracts. An unsupported source or message format requires an accepted adapter contract before connection.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR053-C01-A01, FR053-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR053-C02 · An unsupported source or message format requires an accepted adapter contract before connection.
Parent requirement and conditions: SHARED must provide adapters for institutional data services and device gateways using approved message contracts. An unsupported source or message format requires an accepted adapter contract before connection.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR053-C02-A01, FR053-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR054-C01 · SHARED must retain the source message identity, observed and received times, mapping version, staged-pending rows and rejected-row reasons in each intake receipt.
Parent requirement and conditions: SHARED must retain the source message identity, observed and received times, mapping version, staged-pending rows and rejected-row reasons in each intake receipt.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR054-C01-A01, FR054-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR055-C01 · SHARED must reuse unchanged source events and require an explicit correction for changed content.
Parent requirement and conditions: SHARED must reuse unchanged source events and require an explicit correction for changed content. Keep out-of-order arrival distinct from revision. Retained archive batches must use their documented all-or-none saving and duplicate checks.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR055-C01-A01, FR055-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR055-C02 · Keep out-of-order arrival distinct from revision.
Parent requirement and conditions: SHARED must reuse unchanged source events and require an explicit correction for changed content. Keep out-of-order arrival distinct from revision. Retained archive batches must use their documented all-or-none saving and duplicate checks.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR055-C02-A01, FR055-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR055-C03 · Retained archive batches must use their documented all-or-none saving and duplicate checks.
Parent requirement and conditions: SHARED must reuse unchanged source events and require an explicit correction for changed content. Keep out-of-order arrival distinct from revision. Retained archive batches must use their documented all-or-none saving and duplicate checks.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR055-C03-A01, FR055-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR056-C01 · SHARED must keep connections inactive until a real endpoint, protected machine identity, rights and mapping review have been supplied.
Parent requirement and conditions: SHARED must keep connections inactive until a real endpoint, protected machine identity, rights and mapping review have been supplied.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR056-C01-A01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR057-C01 · SHARED must retain versions, reasons, source references and permitted history for quality issues and observation corrections.
Parent requirement and conditions: SHARED must retain versions, reasons, source references and permitted history for quality issues and observation corrections.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR057-C01-A01, FR057-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
FR058-C01 · SHARED must use the same published checks for numeric values, text, required dates and source identifiers on every entry route.
Parent requirement and conditions: SHARED must use the same published checks for numeric values, text, required dates and source identifiers on every entry route. Changing a rule already used by records requires a reviewed new version.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR058-C01-A01, FR058-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR058-C02 · Changing a rule already used by records requires a reviewed new version.
Parent requirement and conditions: SHARED must use the same published checks for numeric values, text, required dates and source identifiers on every entry route. Changing a rule already used by records requires a reviewed new version.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR058-C02-A01, FR058-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR059-C01 · SHARED must prevent candidate identity suggestions from approving themselves.
Parent requirement and conditions: SHARED must prevent candidate identity suggestions from approving themselves. Link source keys to a permitted registered object only through the reviewed workflow, preserving source-specific scope.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR059-C01-A01, FR059-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR059-C02 · Link source keys to a permitted registered object only through the reviewed workflow, preserving source-specific scope.
Parent requirement and conditions: SHARED must prevent candidate identity suggestions from approving themselves. Link source keys to a permitted registered object only through the reviewed workflow, preserving source-specific scope.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR059-C02-A01, FR059-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR060-C01 · SHARED must retain both originals and their units, places, dates, methods, review and origin when comparing source-reported values.
Parent requirement and conditions: SHARED must retain both originals and their units, places, dates, methods, review and origin when comparing source-reported values. Do not silently average or overwrite conflicting claims.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR060-C01-A01, FR060-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR060-C02 · Do not silently average or overwrite conflicting claims.
Parent requirement and conditions: SHARED must retain both originals and their units, places, dates, methods, review and origin when comparing source-reported values. Do not silently average or overwrite conflicting claims.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR060-C02-A01, FR060-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR061-C01 · When a reviewer chooses a source, record the purpose and evidence for that choice.
Parent requirement and conditions: When a reviewer chooses a source, record the purpose and evidence for that choice. Check that units, place, period, field mapping and review are suitable. Recheck the choice after a source changes.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR061-C01-A01, FR061-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR061-C02 · Check that units, place, period, field mapping and review are suitable.
Parent requirement and conditions: When a reviewer chooses a source, record the purpose and evidence for that choice. Check that units, place, period, field mapping and review are suitable. Recheck the choice after a source changes.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR061-C02-A01, FR061-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR061-C03 · Recheck the choice after a source changes.
Parent requirement and conditions: When a reviewer chooses a source, record the purpose and evidence for that choice. Check that units, place, period, field mapping and review are suitable. Recheck the choice after a source changes.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR061-C03-A01, FR061-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR062-C01 · Provide one worklist for reviewing values, correcting errors and comparing sources.
Parent requirement and conditions: Provide one worklist for reviewing values, correcting errors and comparing sources. Keep versions of field and related-field rules. Experts must approve scientific plausibility checks, calibration and specialist rules before those checks are used.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR062-C01-A01, FR062-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR062-C02 · Keep versions of field and related-field rules.
Parent requirement and conditions: Provide one worklist for reviewing values, correcting errors and comparing sources. Keep versions of field and related-field rules. Experts must approve scientific plausibility checks, calibration and specialist rules before those checks are used.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR062-C02-A01, FR062-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR062-C03 · Experts must approve scientific plausibility checks, calibration and specialist rules before those checks are used.
Parent requirement and conditions: Provide one worklist for reviewing values, correcting errors and comparing sources. Keep versions of field and related-field rules. Experts must approve scientific plausibility checks, calibration and specialist rules before those checks are used.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR062-C03-A01, FR062-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR001-C01 · SHARED must allow authorized administrators to maintain organizations, units, stakeholders and contacts.
Parent requirement and conditions: SHARED must allow authorized administrators to maintain organizations, units, stakeholders and contacts. They must keep these records separate from login accounts and retain deactivation history.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR001-C01-A01, FR001-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR001-C02 · They must keep these records separate from login accounts.
Parent requirement and conditions: SHARED must allow authorized administrators to maintain organizations, units, stakeholders and contacts. They must keep these records separate from login accounts and retain deactivation history.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR001-C02-A01, FR001-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR001-C03 · retain deactivation history.
Parent requirement and conditions: SHARED must allow authorized administrators to maintain organizations, units, stakeholders and contacts. They must keep these records separate from login accounts and retain deactivation history.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR001-C03-A01, FR001-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR002-C01 · SHARED must allow authorized administrators to manage account state, groups, memberships, roles and permissions through audited workflows.
Parent requirement and conditions: SHARED must allow authorized administrators to manage account state, groups, memberships, roles and permissions through audited workflows. Open self-registration must remain disabled unless separately approved.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR002-C01-A01, FR002-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID
FR002-C02 · Open self-registration must remain disabled unless separately approved.
Parent requirement and conditions: SHARED must allow authorized administrators to manage account state, groups, memberships, roles and permissions through audited workflows. Open self-registration must remain disabled unless separately approved.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR002-C02-A01, FR002-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID
FR003-C01 · SHARED must apply the permitted scope and effective dates to every delegation and assignment.
Parent requirement and conditions: SHARED must apply the permitted scope and effective dates to every delegation and assignment. A delegate must not grant powers beyond those they may delegate.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR003-C01-A01, FR003-D01, SC-AUTH-ALLOW, SC-AUTH-DENY
FR003-C02 · A delegate must not grant powers beyond those they may delegate.
Parent requirement and conditions: SHARED must apply the permitted scope and effective dates to every delegation and assignment. A delegate must not grant powers beyond those they may delegate.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR003-C02-A01, FR003-D01, SC-AUTH-ALLOW, SC-AUTH-DENY
FR004-C01 · Provide secure sign-in through an authentication service.
Parent requirement and conditions: SHARED must provide secure sign-in through an authentication service, including standard password hashing, lockout, expiring tokens and revocable sessions. Require multi-factor authentication for platform administrators, privileged access reviewers and other roles identified by the approved security policy.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR004-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR004-C02 · Use standard password hashing.
Parent requirement and conditions: SHARED must provide secure sign-in through an authentication service, including standard password hashing, lockout, expiring tokens and revocable sessions. Require multi-factor authentication for platform administrators, privileged access reviewers and other roles identified by the approved security policy.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR004-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR004-C03 · Apply lockout controls.
Parent requirement and conditions: SHARED must provide secure sign-in through an authentication service, including standard password hashing, lockout, expiring tokens and revocable sessions. Require multi-factor authentication for platform administrators, privileged access reviewers and other roles identified by the approved security policy.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR004-C03-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR004-C04 · Expire sign-in tokens.
Parent requirement and conditions: SHARED must provide secure sign-in through an authentication service, including standard password hashing, lockout, expiring tokens and revocable sessions. Require multi-factor authentication for platform administrators, privileged access reviewers and other roles identified by the approved security policy.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR004-C04-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR004-C05 · Support revocable sessions.
Parent requirement and conditions: SHARED must provide secure sign-in through an authentication service, including standard password hashing, lockout, expiring tokens and revocable sessions. Require multi-factor authentication for platform administrators, privileged access reviewers and other roles identified by the approved security policy.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR004-C05-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR004-C06 · Require multi-factor authentication for platform administrators.
Parent requirement and conditions: SHARED must provide secure sign-in through an authentication service, including standard password hashing, lockout, expiring tokens and revocable sessions. Require multi-factor authentication for platform administrators, privileged access reviewers and other roles identified by the approved security policy.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR004-C06-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR004-C07 · Require multi-factor authentication for privileged access reviewers.
Parent requirement and conditions: SHARED must provide secure sign-in through an authentication service, including standard password hashing, lockout, expiring tokens and revocable sessions. Require multi-factor authentication for platform administrators, privileged access reviewers and other roles identified by the approved security policy.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR004-C07-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR004-C08 · Apply multi-factor authentication to any additional role named by the approved security policy.
Parent requirement and conditions: SHARED must provide secure sign-in through an authentication service, including standard password hashing, lockout, expiring tokens and revocable sessions. Require multi-factor authentication for platform administrators, privileged access reviewers and other roles identified by the approved security policy.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR004-C08-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR005-C01 · SHARED must identify the acting user from validated sign-in on the server.
Parent requirement and conditions: SHARED must identify the acting user from validated sign-in on the server. An identity or scope supplied in a request must not be accepted as proof of permission.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR005-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR005-C02 · An identity or scope supplied in a request must not be accepted as proof of permission.
Parent requirement and conditions: SHARED must identify the acting user from validated sign-in on the server. An identity or scope supplied in a request must not be accepted as proof of permission.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR005-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR006-C01 · SHARED must issue expiring, single-use invitations that activate only the intended account.
Parent requirement and conditions: SHARED must issue expiring, single-use invitations that activate only the intended account. Keep delivery, use and recovery states truthful; do not print invitation secrets in logs.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR006-C01-A01, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH
FR006-C02 · Keep delivery, use and recovery states truthful.
Parent requirement and conditions: SHARED must issue expiring, single-use invitations that activate only the intended account. Keep delivery, use and recovery states truthful; do not print invitation secrets in logs.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR006-C02-A01, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH
FR006-C03 · do not print invitation secrets in logs.
Parent requirement and conditions: SHARED must issue expiring, single-use invitations that activate only the intended account. Keep delivery, use and recovery states truthful; do not print invitation secrets in logs.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR006-C03-A01, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH
FR007-C01 · SHARED must let an authorized administrator select a shared stakeholder context.
Parent requirement and conditions: SHARED must let an authorized administrator select a shared stakeholder context. SHARED must retain the actual acting account and check the chosen context's permissions.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR007-C01-A01, FR007-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
FR007-C02 · SHARED must retain the actual acting account and check the chosen context's permissions.
Parent requirement and conditions: SHARED must let an authorized administrator select a shared stakeholder context. SHARED must retain the actual acting account and check the chosen context's permissions.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR007-C02-A01, FR007-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
FR008-C01 · SHARED must connect organizations, domains, geography, projects, evidence, contributions and discovery through shared identities and workflows.
Parent requirement and conditions: SHARED must connect organizations, domains, geography, projects, evidence, contributions and discovery through shared identities and workflows.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR008-C01-A01, FR008-D01, SC-STATE-VALID, SC-STATE-INVALID
FR009-C01 · Deny an action unless its action scope permits it.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C01-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C02 · Deny an action unless its organization scope permits it.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C02-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C03 · Deny an action unless its stakeholder scope permits it.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C03-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C04 · Deny an action unless its domain scope permits it.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C04-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C05 · Deny an action unless its project scope permits it.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C05-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C06 · Deny an action unless its geography scope permits it.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C06-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C07 · Deny an action unless its record scope permits it.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C07-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C08 · Deny an action unless its classification scope permits it.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C08-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C09 · Deny an action unless its workflow state scope permits it.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C09-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C10 · Use the same permission decision for lists.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C10-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C11 · Use the same permission decision for counts.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C11-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C12 · Use the same permission decision for maps.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C12-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C13 · Use the same permission decision for files.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C13-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR009-C14 · Use the same permission decision for exports.
Parent requirement and conditions: SHARED must deny access unless permitted for the action, organization, stakeholder, domain, project, geography, record, classification and workflow state. Lists, counts, maps, files and exports must follow the same rule.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR009-C14-A01, FR009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR010-C01 · SHARED must allow appointed sharing managers to choose owner-only or selected-stakeholder audiences within shared rules, including dataset overrides.
Parent requirement and conditions: SHARED must allow appointed sharing managers to choose owner-only or selected-stakeholder audiences within shared rules, including dataset overrides. Audit changes and prevent recipient re-sharing or self-delegation.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR010-C01-A01, FR010-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR010-C02 · Audit changes.
Parent requirement and conditions: SHARED must allow appointed sharing managers to choose owner-only or selected-stakeholder audiences within shared rules, including dataset overrides. Audit changes and prevent recipient re-sharing or self-delegation.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR010-C02-A01, FR010-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR010-C03 · prevent recipient re-sharing or self-delegation.
Parent requirement and conditions: SHARED must allow appointed sharing managers to choose owner-only or selected-stakeholder audiences within shared rules, including dataset overrides. Audit changes and prevent recipient re-sharing or self-delegation.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR010-C03-A01, FR010-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR011-C01 · SHARED must retain the approved stakeholder branches and related participants through shared identities.
Parent requirement and conditions: SHARED must retain the approved stakeholder branches and related participants through shared identities. The prototype currently groups these into 15 main branches. This is an editable starting configuration. Adding a participant must not create legal ownership, a login account or access automatically.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR011-C01-A01, FR011-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR011-C02 · The prototype currently groups these into 15 main branches.
Parent requirement and conditions: SHARED must retain the approved stakeholder branches and related participants through shared identities. The prototype currently groups these into 15 main branches. This is an editable starting configuration. Adding a participant must not create legal ownership, a login account or access automatically.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR011-C02-A01, FR011-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR011-C03 · This is an editable starting configuration.
Parent requirement and conditions: SHARED must retain the approved stakeholder branches and related participants through shared identities. The prototype currently groups these into 15 main branches. This is an editable starting configuration. Adding a participant must not create legal ownership, a login account or access automatically.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR011-C03-A01, FR011-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR011-C04 · Adding a participant must not create legal ownership, a login account or access automatically.
Parent requirement and conditions: SHARED must retain the approved stakeholder branches and related participants through shared identities. The prototype currently groups these into 15 main branches. This is an editable starting configuration. Adding a participant must not create legal ownership, a login account or access automatically.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR011-C04-A01, FR011-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR012-C01 · SHARED must allow each owner to maintain its permitted base domains, subjects, attributes and connections.
Parent requirement and conditions: SHARED must allow each owner to maintain its permitted base domains, subjects, attributes and connections. Forest and Wildlife must retain separate ownership. Shared subjects must use reviewed relationships.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR012-C01-A01, FR012-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR012-C02 · Forest and Wildlife must retain separate ownership.
Parent requirement and conditions: SHARED must allow each owner to maintain its permitted base domains, subjects, attributes and connections. Forest and Wildlife must retain separate ownership. Shared subjects must use reviewed relationships.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR012-C02-A01, FR012-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR012-C03 · Shared subjects must use reviewed relationships.
Parent requirement and conditions: SHARED must allow each owner to maintain its permitted base domains, subjects, attributes and connections. Forest and Wildlife must retain separate ownership. Shared subjects must use reviewed relationships.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR012-C03-A01, FR012-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR013-C01 · SHARED must provide configurable dashboard definitions, audiences and saved preferences.
Parent requirement and conditions: SHARED must provide configurable dashboard definitions, audiences and saved preferences. Register proposed products with their purpose, inputs, coverage, approval and acceptance needs; leave proposals inactive.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR013-C01-A01, FR013-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR013-C02 · Register proposed products with their purpose, inputs, coverage, approval and acceptance needs.
Parent requirement and conditions: SHARED must provide configurable dashboard definitions, audiences and saved preferences. Register proposed products with their purpose, inputs, coverage, approval and acceptance needs; leave proposals inactive.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR013-C02-A01, FR013-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR013-C03 · leave proposals inactive.
Parent requirement and conditions: SHARED must provide configurable dashboard definitions, audiences and saved preferences. Register proposed products with their purpose, inputs, coverage, approval and acceptance needs; leave proposals inactive.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR013-C03-A01, FR013-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR014-C01 · SHARED must allow appointed stewards to maintain reviewed domain packs containing schema definitions, vocabularies, units and project or deliverable templates.
Parent requirement and conditions: SHARED must allow appointed stewards to maintain reviewed domain packs containing schema definitions, vocabularies, units and project or deliverable templates.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR014-C01-A01, FR014-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR015-C01 · SHARED must limit configuration to reviewed field types, components, validation, vocabulary, geography and evidence definitions.
Parent requirement and conditions: SHARED must limit configuration to reviewed field types, components, validation, vocabulary, geography and evidence definitions. Reject scripts, executable expressions and unknown properties.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR015-C01-A01, FR015-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR015-C02 · Reject scripts, executable expressions and unknown properties.
Parent requirement and conditions: SHARED must limit configuration to reviewed field types, components, validation, vocabulary, geography and evidence definitions. Reject scripts, executable expressions and unknown properties.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR015-C02-A01, FR015-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR016-C01 · SHARED must keep the exact field definitions and form version used to validate each submitted section.
Parent requirement and conditions: SHARED must keep the exact field definitions and form version used to validate each submitted section. Later template edits must not rewrite that submission.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR016-C01-A01, FR016-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR016-C02 · Later template edits must not rewrite that submission.
Parent requirement and conditions: SHARED must keep the exact field definitions and form version used to validate each submitted section. Later template edits must not rewrite that submission.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR016-C02-A01, FR016-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR017-C01 · SHARED must allow new domains, subjects and attributes that use published supported storage profiles to be configured without deployment.
Parent requirement and conditions: SHARED must allow new domains, subjects and attributes that use published supported storage profiles to be configured without deployment.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR017-C01-A01, FR017-D01, SC-INTERFACE-BAD
FR018-C01 · SHARED must support hierarchy, translations, effective dates, ordering, aliases and retirement in reference lists.
Parent requirement and conditions: SHARED must support hierarchy, translations, effective dates, ordering, aliases and retirement in reference lists. Used identities and meanings must remain stable.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR018-C01-A01, FR018-D01
FR018-C02 · Used identities and meanings must remain stable.
Parent requirement and conditions: SHARED must support hierarchy, translations, effective dates, ordering, aliases and retirement in reference lists. Used identities and meanings must remain stable.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR018-C02-A01, FR018-D01
FR019-C01 · SHARED must link a controlled record to its primary domain and secondary classifications without copying its core record.
Parent requirement and conditions: SHARED must link a controlled record to its primary domain and secondary classifications without copying its core record.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR019-C01-A01, FR019-D01, SC-AUTH-ALLOW, SC-AUTH-DENY
FR020-C01 · SHARED must store the initial domain names, field descriptions and allowed choices as editable settings.
Parent requirement and conditions: SHARED must store the initial domain names, field descriptions and allowed choices as editable settings. They must not be fixed in screen code or supplied as sample business records.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR020-C01-A01, FR020-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR020-C02 · They must not be fixed in screen code or supplied as sample business records.
Parent requirement and conditions: SHARED must store the initial domain names, field descriptions and allowed choices as editable settings. They must not be fixed in screen code or supplied as sample business records.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR020-C02-A01, FR020-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR021-C01 · SHARED must reuse existing meanings, fields and units where they are truly the same.
Parent requirement and conditions: SHARED must reuse existing meanings, fields and units where they are truly the same. Before merging definitions or publishing a change, an authorized reviewer must check possible duplicates and affected records. Similar labels do not prove equal meaning.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR021-C01-A01, FR021-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR021-C02 · Before merging definitions or publishing a change, an authorized reviewer must check possible duplicates and affected records.
Parent requirement and conditions: SHARED must reuse existing meanings, fields and units where they are truly the same. Before merging definitions or publishing a change, an authorized reviewer must check possible duplicates and affected records. Similar labels do not prove equal meaning.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR021-C02-A01, FR021-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR021-C03 · Similar labels do not prove equal meaning.
Parent requirement and conditions: SHARED must reuse existing meanings, fields and units where they are truly the same. Before merging definitions or publishing a change, an authorized reviewer must check possible duplicates and affected records. Similar labels do not prove equal meaning.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR021-C03-A01, FR021-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR022-C01 · SHARED must allow appointed stewards to configure independent geography schemes and levels rather than force all places into one hierarchy.
Parent requirement and conditions: SHARED must allow appointed stewards to configure independent geography schemes and levels rather than force all places into one hierarchy.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR022-C01-A01, FR022-D01
FR023-C01 · Keep each place's stable codes.
Parent requirement and conditions: SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR023-C01-A01, FR023-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR023-C02 · Keep each place's names.
Parent requirement and conditions: SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR023-C02-A01, FR023-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR023-C03 · Keep each place's aliases.
Parent requirement and conditions: SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR023-C03-A01, FR023-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR023-C04 · Keep each place's translations.
Parent requirement and conditions: SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR023-C04-A01, FR023-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR023-C05 · Keep each place's geometry.
Parent requirement and conditions: SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR023-C05-A01, FR023-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR023-C06 · Keep each place's source.
Parent requirement and conditions: SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR023-C06-A01, FR023-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR023-C07 · Keep each place's accuracy.
Parent requirement and conditions: SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR023-C07-A01, FR023-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR023-C08 · Keep each place's dates.
Parent requirement and conditions: SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR023-C08-A01, FR023-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR023-C09 · Keep each place's version.
Parent requirement and conditions: SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR023-C09-A01, FR023-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR023-C10 · Keep each place's status.
Parent requirement and conditions: SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR023-C10-A01, FR023-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR023-C11 · Support the permitted point, line and polygon forms.
Parent requirement and conditions: SHARED must retain each place's stable codes, names, aliases, translations, geometry, source, accuracy, dates, version and status for supported point, line and polygon forms.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR023-C11-A01, FR023-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR024-C01 · SHARED must support reviewed hierarchy, containment, overlap and many-to-many links between schemes.
Parent requirement and conditions: SHARED must support reviewed hierarchy, containment, overlap and many-to-many links between schemes.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR024-C01-A01, FR024-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR025-C01 · SHARED must preserve historical references.
Parent requirement and conditions: SHARED must preserve historical references and prevent deletion of used meanings when a place is replaced, split, merged or retired.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR025-C01-A01, FR025-D01
FR025-C02 · prevent deletion of used meanings when a place is replaced, split, merged or retired.
Parent requirement and conditions: SHARED must preserve historical references and prevent deletion of used meanings when a place is replaced, split, merged or retired.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR025-C02-A01, FR025-D01
FR026-C01 · Check geometry coordinate system.
Parent requirement and conditions: SHARED must check coordinate system, bounds, type, validity, topology, complexity and safe query limits. Unsupported input must fail clearly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR026-C01-A01, FR026-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR026-C02 · Check geometry bounds.
Parent requirement and conditions: SHARED must check coordinate system, bounds, type, validity, topology, complexity and safe query limits. Unsupported input must fail clearly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR026-C02-A01, FR026-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR026-C03 · Check geometry type.
Parent requirement and conditions: SHARED must check coordinate system, bounds, type, validity, topology, complexity and safe query limits. Unsupported input must fail clearly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR026-C03-A01, FR026-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR026-C04 · Check geometry validity.
Parent requirement and conditions: SHARED must check coordinate system, bounds, type, validity, topology, complexity and safe query limits. Unsupported input must fail clearly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR026-C04-A01, FR026-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR026-C05 · Check geometry topology.
Parent requirement and conditions: SHARED must check coordinate system, bounds, type, validity, topology, complexity and safe query limits. Unsupported input must fail clearly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR026-C05-A01, FR026-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR026-C06 · Check geometry complexity.
Parent requirement and conditions: SHARED must check coordinate system, bounds, type, validity, topology, complexity and safe query limits. Unsupported input must fail clearly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR026-C06-A01, FR026-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR026-C07 · Apply safe query limits.
Parent requirement and conditions: SHARED must check coordinate system, bounds, type, validity, topology, complexity and safe query limits. Unsupported input must fail clearly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR026-C07-A01, FR026-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR026-C08 · Return a clear failure for unsupported input.
Parent requirement and conditions: SHARED must check coordinate system, bounds, type, validity, topology, complexity and safe query limits. Unsupported input must fail clearly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR026-C08-A01, FR026-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR027-C01 · SHARED must enforce the configured Draft, Review, Active and Retired lifecycle for boundaries.
Parent requirement and conditions: SHARED must enforce the configured Draft, Review, Active and Retired lifecycle for boundaries. High-impact changes need impact preview and independent approval.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR027-C01-A01, FR027-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR027-C02 · High-impact changes need impact preview and independent approval.
Parent requirement and conditions: SHARED must enforce the configured Draft, Review, Active and Retired lifecycle for boundaries. High-impact changes need impact preview and independent approval.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR027-C02-A01, FR027-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR028-C01 · SHARED must search GN areas through the shared paged geography reader.
Parent requirement and conditions: SHARED must search GN areas through the shared paged geography reader. Keep timeout, missing and denied responses distinct from a valid empty list.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR028-C01-A01
FR028-C02 · Keep timeout, missing and denied responses distinct from a valid empty list.
Parent requirement and conditions: SHARED must search GN areas through the shared paged geography reader. Keep timeout, missing and denied responses distinct from a valid empty list.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR028-C02-A01
FR063-C01 · SHARED must retain each spatial layer version's source type, geometry or raster descriptive information, coordinate system, scale or resolution, coverage, owner and classification.
Parent requirement and conditions: SHARED must retain each spatial layer version's source type, geometry or raster descriptive information, coordinate system, scale or resolution, coverage, owner and classification.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR063-C01-A01, FR063-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR064-C01 · SHARED must make approved map styles, legends, layer groups and saved map workspaces refer to the shared permitted layers.
Parent requirement and conditions: SHARED must make approved map styles, legends, layer groups and saved map workspaces refer to the shared permitted layers. Recheck withdrawn source access.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR064-C01-A01, FR064-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR064-C02 · Recheck withdrawn source access.
Parent requirement and conditions: SHARED must make approved map styles, legends, layer groups and saved map workspaces refer to the shared permitted layers. Recheck withdrawn source access.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR064-C02-A01, FR064-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR065-C01 · SHARED must connect layers to domains, datasets, documents, projects, interventions and geographies without another GIS registry.
Parent requirement and conditions: SHARED must connect layers to domains, datasets, documents, projects, interventions and geographies without another GIS registry.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR065-C01-A01, FR065-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR066-C01 · SHARED must enforce device, volume and location-disclosure limits in web and mobile maps.
Parent requirement and conditions: SHARED must enforce device, volume and location-disclosure limits in web and mobile maps. Sensitive exact locations must be hidden or generalized according to approved rules.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR066-C01-A01, FR066-D01, SC-AUTH-ALLOW, SC-AUTH-DENY
FR066-C02 · Sensitive exact locations must be hidden or generalized according to approved rules.
Parent requirement and conditions: SHARED must enforce device, volume and location-disclosure limits in web and mobile maps. Sensitive exact locations must be hidden or generalized according to approved rules.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR066-C02-A01, FR066-D01, SC-AUTH-ALLOW, SC-AUTH-DENY
FR067-C01 · SHARED must exclude positively identified test and demonstration features from operational maps while preserving their history.
Parent requirement and conditions: SHARED must exclude positively identified test and demonstration features from operational maps while preserving their history. Unknown origin must not be relabelled real.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR067-C01-A01, FR067-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
FR067-C02 · Unknown origin must not be relabelled real.
Parent requirement and conditions: SHARED must exclude positively identified test and demonstration features from operational maps while preserving their history. Unknown origin must not be relabelled real.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR067-C02-A01, FR067-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
FR068-C01 · SHARED must use the shared grouped menu, context and progressive layer loading.
Parent requirement and conditions: SHARED must use the shared grouped menu, context and progressive layer loading. Cancel old requests and distinguish missing, denied, failed and valid empty results.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR068-C01-A01, FR068-D01, SC-RETRY-SAME, SC-RETRY-CRASH
FR068-C02 · Cancel old requests.
Parent requirement and conditions: SHARED must use the shared grouped menu, context and progressive layer loading. Cancel old requests and distinguish missing, denied, failed and valid empty results.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR068-C02-A01, FR068-D01, SC-RETRY-SAME, SC-RETRY-CRASH
FR068-C03 · distinguish missing, denied, failed and valid empty results.
Parent requirement and conditions: SHARED must use the shared grouped menu, context and progressive layer loading. Cancel old requests and distinguish missing, denied, failed and valid empty results.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR068-C03-A01, FR068-D01, SC-RETRY-SAME, SC-RETRY-CRASH
FR069-C01 · SHARED must support the specified approximate buffer, loaded-feature proximity, selected-polygon overlap and area tools with method, units, inputs and limits.
Parent requirement and conditions: SHARED must support the specified approximate buffer, loaded-feature proximity, selected-polygon overlap and area tools with method, units, inputs and limits.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR069-C01-A01, FR069-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR070-C01 · SHARED must use actual points.
Parent requirement and conditions: SHARED must use actual points and retain scale, denominators and non-estimable states for clustering, record-density grids and exploratory hotspot counts. Do not invent point centres or risk classes.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR070-C01-A01, FR070-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR070-C02 · retain scale, denominators and non-estimable states for clustering, record-density grids and exploratory hotspot counts.
Parent requirement and conditions: SHARED must use actual points and retain scale, denominators and non-estimable states for clustering, record-density grids and exploratory hotspot counts. Do not invent point centres or risk classes.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR070-C02-A01, FR070-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR070-C03 · Do not invent point centres or risk classes.
Parent requirement and conditions: SHARED must use actual points and retain scale, denominators and non-estimable states for clustering, record-density grids and exploratory hotspot counts. Do not invent point centres or risk classes.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR070-C03-A01, FR070-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR071-C01 · SHARED must check coordinate system, grid alignment, units, class meaning and missing cells before supported raster preview, swipe, native-cell summary or change analysis.
Parent requirement and conditions: SHARED must check coordinate system, grid alignment, units, class meaning and missing cells before supported raster preview, swipe, native-cell summary or change analysis.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR071-C01-A01, FR071-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR072-C01 · SHARED must keep source versions, context, parameters, fingerprints, limits and outputs.
Parent requirement and conditions: SHARED must keep source versions, context, parameters, fingerprints, limits and outputs. Bound background work, support cancellation and invalidate results after source change.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR072-C01-A01, FR072-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR072-C02 · Bound background work, support cancellation.
Parent requirement and conditions: SHARED must keep source versions, context, parameters, fingerprints, limits and outputs. Bound background work, support cancellation and invalidate results after source change.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR072-C02-A01, FR072-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR072-C03 · invalidate results after source change.
Parent requirement and conditions: SHARED must keep source versions, context, parameters, fingerprints, limits and outputs. Bound background work, support cancellation and invalidate results after source change.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR072-C03-A01, FR072-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR073-C01 · SHARED must use the shared source and version workflow for exact lawful originals and supported normalized points or native raster cells.
Parent requirement and conditions: SHARED must use the shared source and version workflow for exact lawful originals and supported normalized points or native raster cells. Preserve coordinates, source dates and missing cells.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR073-C01-A01, FR073-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR073-C02 · Preserve coordinates, source dates and missing cells.
Parent requirement and conditions: SHARED must use the shared source and version workflow for exact lawful originals and supported normalized points or native raster cells. Preserve coordinates, source dates and missing cells.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR073-C02-A01, FR073-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR074-C01 · SHARED must keep a pending spatial layer unpublished during ingestion.
Parent requirement and conditions: SHARED must keep a pending spatial layer unpublished during ingestion. Apply archive, geometry, extent and supported transformation controls. General conversion, national tiling or every GIS file type must not be claimed.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR074-C01-A01, FR074-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR074-C02 · Apply archive, geometry, extent and supported transformation controls.
Parent requirement and conditions: SHARED must keep a pending spatial layer unpublished during ingestion. Apply archive, geometry, extent and supported transformation controls. General conversion, national tiling or every GIS file type must not be claimed.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR074-C02-A01, FR074-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR074-C03 · General conversion, national tiling or every GIS file type must not be claimed.
Parent requirement and conditions: SHARED must keep a pending spatial layer unpublished during ingestion. Apply archive, geometry, extent and supported transformation controls. General conversion, national tiling or every GIS file type must not be claimed.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR074-C03-A01, FR074-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR075-C01 · SHARED must retain source product, variable, location, unit, observation period, receipt time, issue time and forecast validity where supplied.
Parent requirement and conditions: SHARED must retain source product, variable, location, unit, observation period, receipt time, issue time and forecast validity where supplied.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR075-C01-A01, FR075-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR076-C01 · SHARED must show overdue or failed source acquisition and expired retained forecasts in source-refresh views.
Parent requirement and conditions: SHARED must show overdue or failed source acquisition and expired retained forecasts in source-refresh views. Unknown source or period must remain unknown.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR076-C01-A01, FR076-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
FR076-C02 · Unknown source or period must remain unknown.
Parent requirement and conditions: SHARED must show overdue or failed source acquisition and expired retained forecasts in source-refresh views. Unknown source or period must remain unknown.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR076-C02-A01, FR076-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
FR077-C01 · SHARED must retain the original grid location, period, units, references and origin of retained rainfall source series.
Parent requirement and conditions: SHARED must retain the original grid location, period, units, references and origin of retained rainfall source series. Do not invent a GN assignment or new station.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR077-C01-A01, FR077-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR077-C02 · Do not invent a GN assignment or new station.
Parent requirement and conditions: SHARED must retain the original grid location, period, units, references and origin of retained rainfall source series. Do not invent a GN assignment or new station.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR077-C02-A01, FR077-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR078-C01 · SHARED must require suitable dated records or an approved allocation method for a complete GN rainfall and cultivation comparison.
Parent requirement and conditions: SHARED must require suitable dated records or an approved allocation method for a complete GN rainfall and cultivation comparison. An undated classification or district statistic cannot supply five annual GN totals.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR078-C01-A01, FR078-D01, SC-AUTH-ALLOW, SC-AUTH-DENY
FR078-C02 · An undated classification or district statistic cannot supply five annual GN totals.
Parent requirement and conditions: SHARED must require suitable dated records or an approved allocation method for a complete GN rainfall and cultivation comparison. An undated classification or district statistic cannot supply five annual GN totals.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR078-C02-A01, FR078-D01, SC-AUTH-ALLOW, SC-AUTH-DENY
FR079-C01 · SHARED must require the relevant accepted method, inputs and authority before presenting operational hazard, drought, adaptation or warning outputs.
Parent requirement and conditions: SHARED must require the relevant accepted method, inputs and authority before presenting operational hazard, drought, adaptation or warning outputs. Recorded context must not become an official warning automatically.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR079-C01-A01, FR079-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR079-C02 · Recorded context must not become an official warning automatically.
Parent requirement and conditions: SHARED must require the relevant accepted method, inputs and authority before presenting operational hazard, drought, adaptation or warning outputs. Recorded context must not become an official warning automatically.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR079-C02-A01, FR079-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR080-C01 · SHARED must reuse society or farmer-group profiles, members, farm plots and plot-crop records with their owner, source, area and permitted review states.
Parent requirement and conditions: SHARED must reuse society or farmer-group profiles, members, farm plots and plot-crop records with their owner, source, area and permitted review states.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR080-C01-A01, FR080-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR081-C01 · SHARED must link farming activities, problems, actions and evidence to the relevant plot, crop, project and workflow.
Parent requirement and conditions: SHARED must link farming activities, problems, actions and evidence to the relevant plot, crop, project and workflow.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR081-C01-A01, FR081-D01, SC-STATE-VALID, SC-STATE-INVALID
SH-GEO-FEAT-001-C01 · Each geographic record type must identify its owning institution, domain, subject, business object, allowed geometry, required and optional fields, place and time rules, source and evidence, validation, review workflow, map style, classification and access.
Parent requirement and conditions: Each geographic record type must identify its owning institution, domain, subject, business object, allowed geometry, required and optional fields, place and time rules, source and evidence, validation, review workflow, map style, classification and access. Authorised stewards configure the type through the shared definitions.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-001-C01-A01, SH-GEO-FEAT-001-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
SH-GEO-FEAT-001-C02 · Authorised stewards configure the type through the shared definitions.
Parent requirement and conditions: Each geographic record type must identify its owning institution, domain, subject, business object, allowed geometry, required and optional fields, place and time rules, source and evidence, validation, review workflow, map style, classification and access. Authorised stewards configure the type through the shared definitions.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-001-C02-A01, SH-GEO-FEAT-001-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
SH-GEO-FEAT-002-C01 · Authorised users must select the domain and record type, then choose an existing area or feature, enter coordinates, drop a point, or draw a line, polygon or supported multipart feature.
Parent requirement and conditions: Authorised users must select the domain and record type, then choose an existing area or feature, enter coordinates, drop a point, or draw a line, polygon or supported multipart feature. Show only applicable fields and save the geometry or reference as a draft with the related business information.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-002-C01-A01, SH-GEO-FEAT-002-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
SH-GEO-FEAT-002-C02 · Show only applicable fields and save the geometry or reference as a draft with the related business information.
Parent requirement and conditions: Authorised users must select the domain and record type, then choose an existing area or feature, enter coordinates, drop a point, or draw a line, polygon or supported multipart feature. Show only applicable fields and save the geometry or reference as a draft with the related business information.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-002-C02-A01, SH-GEO-FEAT-002-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
SH-GEO-FEAT-003-C01 · Keep a known administrative area separate from the actual occurrence or affected extent.
Parent requirement and conditions: Keep a known administrative area separate from the actual occurrence or affected extent. Allow an area-only record when a precise location is unknown. Retain positional accuracy, uncertainty and source description for approximate points. Never invent coordinates, centroids or polygons to satisfy a field.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-003-C01-A01, SH-GEO-FEAT-003-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-003-C02 · Allow an area-only record when a precise location is unknown.
Parent requirement and conditions: Keep a known administrative area separate from the actual occurrence or affected extent. Allow an area-only record when a precise location is unknown. Retain positional accuracy, uncertainty and source description for approximate points. Never invent coordinates, centroids or polygons to satisfy a field.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-003-C02-A01, SH-GEO-FEAT-003-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-003-C03 · Retain positional accuracy, uncertainty and source description for approximate points.
Parent requirement and conditions: Keep a known administrative area separate from the actual occurrence or affected extent. Allow an area-only record when a precise location is unknown. Retain positional accuracy, uncertainty and source description for approximate points. Never invent coordinates, centroids or polygons to satisfy a field.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-003-C03-A01, SH-GEO-FEAT-003-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-003-C04 · Never invent coordinates, centroids or polygons to satisfy a field.
Parent requirement and conditions: Keep a known administrative area separate from the actual occurrence or affected extent. Allow an area-only record when a precise location is unknown. Retain positional accuracy, uncertainty and source description for approximate points. Never invent coordinates, centroids or polygons to satisfy a field.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-003-C04-A01, SH-GEO-FEAT-003-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-004-C01 · One record may have several geographic representations: reported location, observed extent, surveyed footprint, investigation area, model assessment, proposed intervention and monitoring area.
Parent requirement and conditions: One record may have several geographic representations: reported location, observed extent, surveyed footprint, investigation area, model assessment, proposed intervention and monitoring area. Each representation must retain its role, source, applicable period, accuracy and version. Do not silently combine these roles.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-004-C01-A01, SH-GEO-FEAT-004-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-004-C02 · Each representation must retain its role, source, applicable period, accuracy and version.
Parent requirement and conditions: One record may have several geographic representations: reported location, observed extent, surveyed footprint, investigation area, model assessment, proposed intervention and monitoring area. Each representation must retain its role, source, applicable period, accuracy and version. Do not silently combine these roles.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-004-C02-A01, SH-GEO-FEAT-004-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-004-C03 · Do not silently combine these roles.
Parent requirement and conditions: One record may have several geographic representations: reported location, observed extent, surveyed footprint, investigation area, model assessment, proposed intervention and monitoring area. Each representation must retain its role, source, applicable period, accuracy and version. Do not silently combine these roles.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-004-C03-A01, SH-GEO-FEAT-004-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-005-C01 · Use the domain owner's published field definitions and reuse equivalent fields.
Parent requirement and conditions: Use the domain owner's published field definitions and reuse equivalent fields. Incident, wildlife, crop suitability and other record types may need different attributes and review rules. The owner confirms the field meanings, required state, units and allowed values before publication.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-005-C01-A01, SH-GEO-FEAT-005-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
SH-GEO-FEAT-005-C02 · Incident, wildlife, crop suitability and other record types may need different attributes and review rules.
Parent requirement and conditions: Use the domain owner's published field definitions and reuse equivalent fields. Incident, wildlife, crop suitability and other record types may need different attributes and review rules. The owner confirms the field meanings, required state, units and allowed values before publication.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-005-C02-A01, SH-GEO-FEAT-005-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
SH-GEO-FEAT-005-C03 · The owner confirms the field meanings, required state, units and allowed values before publication.
Parent requirement and conditions: Use the domain owner's published field definitions and reuse equivalent fields. Incident, wildlife, crop suitability and other record types may need different attributes and review rules. The owner confirms the field meanings, required state, units and allowed values before publication.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-005-C03-A01, SH-GEO-FEAT-005-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
SH-GEO-FEAT-006-C01 · Support approved manual drawing, field and mobile surveys, coordinate entry, existing feature selection, GIS imports, institutional APIs and remote-sensing products.
Parent requirement and conditions: Support approved manual drawing, field and mobile surveys, coordinate entry, existing feature selection, GIS imports, institutional APIs and remote-sensing products. AI-suggested geographic references require the approved document-processing route. Every route uses shared source registration, mapping, validation and review.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-006-C01-A01, SH-GEO-FEAT-006-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
SH-GEO-FEAT-006-C02 · AI-suggested geographic references require the approved document-processing route.
Parent requirement and conditions: Support approved manual drawing, field and mobile surveys, coordinate entry, existing feature selection, GIS imports, institutional APIs and remote-sensing products. AI-suggested geographic references require the approved document-processing route. Every route uses shared source registration, mapping, validation and review.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-006-C02-A01, SH-GEO-FEAT-006-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
SH-GEO-FEAT-006-C03 · Every route uses shared source registration, mapping, validation and review.
Parent requirement and conditions: Support approved manual drawing, field and mobile surveys, coordinate entry, existing feature selection, GIS imports, institutional APIs and remote-sensing products. AI-suggested geographic references require the approved document-processing route. Every route uses shared source registration, mapping, validation and review.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-006-C03-A01, SH-GEO-FEAT-006-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
SH-GEO-FEAT-007-C01 · Validate coordinate system for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C01-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C02 · Validate axis order for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C02-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C03 · Validate ranges for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C03-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C04 · Validate geometry type for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C04-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C05 · Validate empty shapes for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C05-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C06 · Validate polygon closure for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C06-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C07 · Validate self-intersection for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C07-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C08 · Validate topology for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C08-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C09 · Validate extent for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C09-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C10 · Validate time for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C10-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C11 · Validate units for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C11-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C12 · Validate required fields for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C12-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C13 · Validate duplicate submissions for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C13-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C14 · Validate object relationships for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C14-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C15 · Validate source version for a geographic record.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C15-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C16 · Apply complexity limits.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C16-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-007-C17 · Return clear correction details.
Parent requirement and conditions: Validate coordinate system, axis order, ranges, geometry type, empty shapes, polygon closure, self-intersection, topology, extent, time, units, required fields, duplicate submissions, object relationships and source version. Apply complexity limits and return clear correction details.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-007-C17-A01, SH-GEO-FEAT-007-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-008-C01 · Reviewers must inspect the submitted geometry, original source, field mappings, accuracy, related records, existing layers, validation, earlier versions and evidence.
Parent requirement and conditions: Reviewers must inspect the submitted geometry, original source, field mappings, accuracy, related records, existing layers, validation, earlier versions and evidence. Record acceptance, return, rejection or required correction under the approved workflow. Technical validity alone cannot approve a geographic feature.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-008-C01-A01, SH-GEO-FEAT-008-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
SH-GEO-FEAT-008-C02 · Record acceptance, return, rejection or required correction under the approved workflow.
Parent requirement and conditions: Reviewers must inspect the submitted geometry, original source, field mappings, accuracy, related records, existing layers, validation, earlier versions and evidence. Record acceptance, return, rejection or required correction under the approved workflow. Technical validity alone cannot approve a geographic feature.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-008-C02-A01, SH-GEO-FEAT-008-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
SH-GEO-FEAT-008-C03 · Technical validity alone cannot approve a geographic feature.
Parent requirement and conditions: Reviewers must inspect the submitted geometry, original source, field mappings, accuracy, related records, existing layers, validation, earlier versions and evidence. Record acceptance, return, rejection or required correction under the approved workflow. Technical validity alone cannot approve a geographic feature.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-008-C03-A01, SH-GEO-FEAT-008-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
SH-GEO-FEAT-009-C01 · Preserve the source institution, custodian, classification and permitted audience of every geographic claim.
Parent requirement and conditions: Preserve the source institution, custodian, classification and permitted audience of every geographic claim. Different institutions may report on the same occurrence. Reviewed matching may link the reports without deleting originals or transferring ownership.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-009-C01-A01, SH-GEO-FEAT-009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
SH-GEO-FEAT-009-C02 · Different institutions may report on the same occurrence.
Parent requirement and conditions: Preserve the source institution, custodian, classification and permitted audience of every geographic claim. Different institutions may report on the same occurrence. Reviewed matching may link the reports without deleting originals or transferring ownership.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-009-C02-A01, SH-GEO-FEAT-009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
SH-GEO-FEAT-009-C03 · Reviewed matching may link the reports without deleting originals or transferring ownership.
Parent requirement and conditions: Preserve the source institution, custodian, classification and permitted audience of every geographic claim. Different institutions may report on the same occurrence. Reviewed matching may link the reports without deleting originals or transferring ownership.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-009-C03-A01, SH-GEO-FEAT-009-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
SH-GEO-FEAT-010-C01 · Preserve corrections, earlier geometry versions and reasons.
Parent requirement and conditions: Preserve corrections, earlier geometry versions and reasons. A later surveyed footprint links to the original approximate record. Authorised users can inspect the historical evidence and change history.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-010-C01-A01, SH-GEO-FEAT-010-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-010-C02 · A later surveyed footprint links to the original approximate record.
Parent requirement and conditions: Preserve corrections, earlier geometry versions and reasons. A later surveyed footprint links to the original approximate record. Authorised users can inspect the historical evidence and change history.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-010-C02-A01, SH-GEO-FEAT-010-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-010-C03 · Authorised users can inspect the historical evidence and change history.
Parent requirement and conditions: Preserve corrections, earlier geometry versions and reasons. A later surveyed footprint links to the original approximate record. Authorised users can inspect the historical evidence and change history.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-010-C03-A01, SH-GEO-FEAT-010-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-011-C01 · Keep occurrence, observation, reporting, survey, assessment, validity, entry and revision times distinct where relevant.
Parent requirement and conditions: Keep occurrence, observation, reporting, survey, assessment, validity, entry and revision times distinct where relevant. Allow historical and reporting-period filters. A past flood extent must not be displayed as a current flood simply because its record is opened.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-011-C01-A01, SH-GEO-FEAT-011-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-011-C02 · Allow historical and reporting-period filters.
Parent requirement and conditions: Keep occurrence, observation, reporting, survey, assessment, validity, entry and revision times distinct where relevant. Allow historical and reporting-period filters. A past flood extent must not be displayed as a current flood simply because its record is opened.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-011-C02-A01, SH-GEO-FEAT-011-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-011-C03 · A past flood extent must not be displayed as a current flood simply because its record is opened.
Parent requirement and conditions: Keep occurrence, observation, reporting, survey, assessment, validity, entry and revision times distinct where relevant. Allow historical and reporting-period filters. A past flood extent must not be displayed as a current flood simply because its record is opened.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-011-C03-A01, SH-GEO-FEAT-011-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-012-C01 · Expose permitted accepted records through the shared Map Explorer and spatial catalogue.
Parent requirement and conditions: Expose permitted accepted records through the shared Map Explorer and spatial catalogue. Reuse existing layers, styles, geography references and services. Use governed feature collections where appropriate rather than a new catalogue, engine or physical layer for every institution or event.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
SH-GEO-FEAT-012-C02 · Reuse existing layers, styles, geography references and services.
Parent requirement and conditions: Expose permitted accepted records through the shared Map Explorer and spatial catalogue. Reuse existing layers, styles, geography references and services. Use governed feature collections where appropriate rather than a new catalogue, engine or physical layer for every institution or event.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
SH-GEO-FEAT-012-C03 · Use governed feature collections where appropriate rather than a new catalogue, engine or physical layer for every institution or event.
Parent requirement and conditions: Expose permitted accepted records through the shared Map Explorer and spatial catalogue. Reuse existing layers, styles, geography references and services. Use governed feature collections where appropriate rather than a new catalogue, engine or physical layer for every institution or event.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
SH-GEO-FEAT-013-C01 · Configure symbols, legends and styles for record types and geographic roles.
Parent requirement and conditions: Configure symbols, legends and styles for record types and geographic roles. Distinguish incidents, surveyed extents, suitability assessments, proposed interventions and unreviewed observations. Colour alone must not communicate approval, severity, hazard or suitability.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-013-C01-A01, SH-GEO-FEAT-013-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
SH-GEO-FEAT-013-C02 · Distinguish incidents, surveyed extents, suitability assessments, proposed interventions and unreviewed observations.
Parent requirement and conditions: Configure symbols, legends and styles for record types and geographic roles. Distinguish incidents, surveyed extents, suitability assessments, proposed interventions and unreviewed observations. Colour alone must not communicate approval, severity, hazard or suitability.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-013-C02-A01, SH-GEO-FEAT-013-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
SH-GEO-FEAT-013-C03 · Colour alone must not communicate approval, severity, hazard or suitability.
Parent requirement and conditions: Configure symbols, legends and styles for record types and geographic roles. Distinguish incidents, surveyed extents, suitability assessments, proposed interventions and unreviewed observations. Colour alone must not communicate approval, severity, hazard or suitability.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-013-C03-A01, SH-GEO-FEAT-013-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
SH-GEO-FEAT-014-C01 · Permit supported area, distance, overlap, intersection, containment, proximity, administrative aggregation, temporal comparison, counts and overlay analyses.
Parent requirement and conditions: Permit supported area, distance, overlap, intersection, containment, proximity, administrative aggregation, temporal comparison, counts and overlay analyses. Retain the actual source geometry, method, units, limits and derived-result evidence. Do not imply unsupported scientific accuracy.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-014-C01-A01, SH-GEO-FEAT-014-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-014-C02 · Retain the actual source geometry, method, units, limits and derived-result evidence.
Parent requirement and conditions: Permit supported area, distance, overlap, intersection, containment, proximity, administrative aggregation, temporal comparison, counts and overlay analyses. Retain the actual source geometry, method, units, limits and derived-result evidence. Do not imply unsupported scientific accuracy.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-014-C02-A01, SH-GEO-FEAT-014-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-014-C03 · Do not imply unsupported scientific accuracy.
Parent requirement and conditions: Permit supported area, distance, overlap, intersection, containment, proximity, administrative aggregation, temporal comparison, counts and overlay analyses. Retain the actual source geometry, method, units, limits and derived-result evidence. Do not imply unsupported scientific accuracy.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-014-C03-A01, SH-GEO-FEAT-014-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
SH-GEO-FEAT-015-C01 · Reuse the same accepted geographic identity across permitted map, location profile, domain dashboard, expert, planning, decision, project and PMU views.
Parent requirement and conditions: Reuse the same accepted geographic identity across permitted map, location profile, domain dashboard, expert, planning, decision, project and PMU views. Links must preserve the governed source, version and access rules.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-015-C01-A01, SH-GEO-FEAT-015-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
SH-GEO-FEAT-015-C02 · Links must preserve the governed source, version and access rules.
Parent requirement and conditions: Reuse the same accepted geographic identity across permitted map, location profile, domain dashboard, expert, planning, decision, project and PMU views. Links must preserve the governed source, version and access rules.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-015-C02-A01, SH-GEO-FEAT-015-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
SH-GEO-FEAT-016-C01 · Provide the appropriate authorised edit, field survey, API, GIS import or source-synchronisation route for each record or layer.
Parent requirement and conditions: Provide the appropriate authorised edit, field survey, API, GIS import or source-synchronisation route for each record or layer. Preserve source and geometry history. Operational users must not edit database records directly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-016-C01-A01, SH-GEO-FEAT-016-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
SH-GEO-FEAT-016-C02 · Preserve source and geometry history.
Parent requirement and conditions: Provide the appropriate authorised edit, field survey, API, GIS import or source-synchronisation route for each record or layer. Preserve source and geometry history. Operational users must not edit database records directly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-016-C02-A01, SH-GEO-FEAT-016-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
SH-GEO-FEAT-016-C03 · Operational users must not edit database records directly.
Parent requirement and conditions: Provide the appropriate authorised edit, field survey, API, GIS import or source-synchronisation route for each record or layer. Preserve source and geometry history. Operational users must not edit database records directly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-016-C03-A01, SH-GEO-FEAT-016-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
SH-GEO-FEAT-017-C01 · Within the agreed responsive field journey, allow authorised users to capture geographic points, accuracy, permitted geometry, photographs and actual observation time where the selected device supports them.
Parent requirement and conditions: Within the agreed responsive field journey, allow authorised users to capture geographic points, accuracy, permitted geometry, photographs and actual observation time where the selected device supports them. An additional field-access channel and offline drafts are proposed options under C01, C06 and C07. If selected, protect drafts and synchronise through the common authenticated service interfaces. Synchronisation alone must not publish an unreviewed record.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-017-C01-A01, SH-GEO-FEAT-017-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
SH-GEO-FEAT-017-C02 · An additional field-access channel and offline drafts are proposed options under C01, C06 and C07.
Parent requirement and conditions: Within the agreed responsive field journey, allow authorised users to capture geographic points, accuracy, permitted geometry, photographs and actual observation time where the selected device supports them. An additional field-access channel and offline drafts are proposed options under C01, C06 and C07. If selected, protect drafts and synchronise through the common authenticated service interfaces. Synchronisation alone must not publish an unreviewed record.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-017-C02-A01, SH-GEO-FEAT-017-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
SH-GEO-FEAT-017-C03 · If selected, protect drafts and synchronise through the common authenticated service interfaces.
Parent requirement and conditions: Within the agreed responsive field journey, allow authorised users to capture geographic points, accuracy, permitted geometry, photographs and actual observation time where the selected device supports them. An additional field-access channel and offline drafts are proposed options under C01, C06 and C07. If selected, protect drafts and synchronise through the common authenticated service interfaces. Synchronisation alone must not publish an unreviewed record.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-017-C03-A01, SH-GEO-FEAT-017-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
SH-GEO-FEAT-017-C04 · Synchronisation alone must not publish an unreviewed record.
Parent requirement and conditions: Within the agreed responsive field journey, allow authorised users to capture geographic points, accuracy, permitted geometry, photographs and actual observation time where the selected device supports them. An additional field-access channel and offline drafts are proposed options under C01, C06 and C07. If selected, protect drafts and synchronise through the common authenticated service interfaces. Synchronisation alone must not publish an unreviewed record.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-017-C04-A01, SH-GEO-FEAT-017-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
SH-GEO-FEAT-018-C01 · Show source, actual observation or occurrence time, geometry role, accuracy, review and approval state, version and real, reference or demonstration origin in maps and record details.
Parent requirement and conditions: Show source, actual observation or occurrence time, geometry role, accuracy, review and approval state, version and real, reference or demonstration origin in maps and record details. Keep unavailable information explicitly unknown.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-018-C01-A01, SH-GEO-FEAT-018-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
SH-GEO-FEAT-018-C02 · Keep unavailable information explicitly unknown.
Parent requirement and conditions: Show source, actual observation or occurrence time, geometry role, accuracy, review and approval state, version and real, reference or demonstration origin in maps and record details. Keep unavailable information explicitly unknown.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-018-C02-A01, SH-GEO-FEAT-018-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
SH-GEO-FEAT-019-C01 · Apply complete institutional ownership and permission rules to geographic features, service responses, maps, search, counts and exports.
Parent requirement and conditions: Apply complete institutional ownership and permission rules to geographic features, service responses, maps, search, counts and exports. Protect sensitive wildlife locations, personal information and restricted records. For fresh public access, use one shared eligibility rule for publication state, classification, audience, required source identity, exact permitted source version, approved use rights, expiry and source or citation dependencies. Re-evaluate on read and export, including dependent cached outputs. Suppress public access when a required dependency is withdrawn, expired, restricted, missing, cyclic or no longer authorised for the requested use. Do not assume the newest version is approved or reject an older version that remains explicitly permitted. Preserve authorised internal records, provenance and history. Previously downloaded copies outside SHARED cannot be recalled.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-019-C01-A01, SH-GEO-FEAT-019-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
SH-GEO-FEAT-019-C02 · Protect sensitive wildlife locations, personal information and restricted records.
Parent requirement and conditions: Apply complete institutional ownership and permission rules to geographic features, service responses, maps, search, counts and exports. Protect sensitive wildlife locations, personal information and restricted records. For fresh public access, use one shared eligibility rule for publication state, classification, audience, required source identity, exact permitted source version, approved use rights, expiry and source or citation dependencies. Re-evaluate on read and export, including dependent cached outputs. Suppress public access when a required dependency is withdrawn, expired, restricted, missing, cyclic or no longer authorised for the requested use. Do not assume the newest version is approved or reject an older version that remains explicitly permitted. Preserve authorised internal records, provenance and history. Previously downloaded copies outside SHARED cannot be recalled.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-019-C02-A01, SH-GEO-FEAT-019-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
SH-GEO-FEAT-019-C03 · For fresh public access, use one shared eligibility rule for publication state, classification, audience, required source identity, exact permitted source version, approved use rights, expiry and source or citation dependencies.
Parent requirement and conditions: Apply complete institutional ownership and permission rules to geographic features, service responses, maps, search, counts and exports. Protect sensitive wildlife locations, personal information and restricted records. For fresh public access, use one shared eligibility rule for publication state, classification, audience, required source identity, exact permitted source version, approved use rights, expiry and source or citation dependencies. Re-evaluate on read and export, including dependent cached outputs. Suppress public access when a required dependency is withdrawn, expired, restricted, missing, cyclic or no longer authorised for the requested use. Do not assume the newest version is approved or reject an older version that remains explicitly permitted. Preserve authorised internal records, provenance and history. Previously downloaded copies outside SHARED cannot be recalled.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-019-C03-A01, SH-GEO-FEAT-019-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
SH-GEO-FEAT-019-C04 · Re-evaluate on read and export, including dependent cached outputs.
Parent requirement and conditions: Apply complete institutional ownership and permission rules to geographic features, service responses, maps, search, counts and exports. Protect sensitive wildlife locations, personal information and restricted records. For fresh public access, use one shared eligibility rule for publication state, classification, audience, required source identity, exact permitted source version, approved use rights, expiry and source or citation dependencies. Re-evaluate on read and export, including dependent cached outputs. Suppress public access when a required dependency is withdrawn, expired, restricted, missing, cyclic or no longer authorised for the requested use. Do not assume the newest version is approved or reject an older version that remains explicitly permitted. Preserve authorised internal records, provenance and history. Previously downloaded copies outside SHARED cannot be recalled.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-019-C04-A01, SH-GEO-FEAT-019-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
SH-GEO-FEAT-019-C05 · Suppress public access when a required dependency is withdrawn, expired, restricted, missing, cyclic or no longer authorised for the requested use.
Parent requirement and conditions: Apply complete institutional ownership and permission rules to geographic features, service responses, maps, search, counts and exports. Protect sensitive wildlife locations, personal information and restricted records. For fresh public access, use one shared eligibility rule for publication state, classification, audience, required source identity, exact permitted source version, approved use rights, expiry and source or citation dependencies. Re-evaluate on read and export, including dependent cached outputs. Suppress public access when a required dependency is withdrawn, expired, restricted, missing, cyclic or no longer authorised for the requested use. Do not assume the newest version is approved or reject an older version that remains explicitly permitted. Preserve authorised internal records, provenance and history. Previously downloaded copies outside SHARED cannot be recalled.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-019-C05-A01, SH-GEO-FEAT-019-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
SH-GEO-FEAT-019-C06 · Do not assume the newest version is approved or reject an older version that remains explicitly permitted.
Parent requirement and conditions: Apply complete institutional ownership and permission rules to geographic features, service responses, maps, search, counts and exports. Protect sensitive wildlife locations, personal information and restricted records. For fresh public access, use one shared eligibility rule for publication state, classification, audience, required source identity, exact permitted source version, approved use rights, expiry and source or citation dependencies. Re-evaluate on read and export, including dependent cached outputs. Suppress public access when a required dependency is withdrawn, expired, restricted, missing, cyclic or no longer authorised for the requested use. Do not assume the newest version is approved or reject an older version that remains explicitly permitted. Preserve authorised internal records, provenance and history. Previously downloaded copies outside SHARED cannot be recalled.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-019-C06-A01, SH-GEO-FEAT-019-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
SH-GEO-FEAT-019-C07 · Preserve authorised internal records, provenance and history.
Parent requirement and conditions: Apply complete institutional ownership and permission rules to geographic features, service responses, maps, search, counts and exports. Protect sensitive wildlife locations, personal information and restricted records. For fresh public access, use one shared eligibility rule for publication state, classification, audience, required source identity, exact permitted source version, approved use rights, expiry and source or citation dependencies. Re-evaluate on read and export, including dependent cached outputs. Suppress public access when a required dependency is withdrawn, expired, restricted, missing, cyclic or no longer authorised for the requested use. Do not assume the newest version is approved or reject an older version that remains explicitly permitted. Preserve authorised internal records, provenance and history. Previously downloaded copies outside SHARED cannot be recalled.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-019-C07-A01, SH-GEO-FEAT-019-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
SH-GEO-FEAT-019-C08 · Previously downloaded copies outside SHARED cannot be recalled.
Parent requirement and conditions: Apply complete institutional ownership and permission rules to geographic features, service responses, maps, search, counts and exports. Protect sensitive wildlife locations, personal information and restricted records. For fresh public access, use one shared eligibility rule for publication state, classification, audience, required source identity, exact permitted source version, approved use rights, expiry and source or citation dependencies. Re-evaluate on read and export, including dependent cached outputs. Suppress public access when a required dependency is withdrawn, expired, restricted, missing, cyclic or no longer authorised for the requested use. Do not assume the newest version is approved or reject an older version that remains explicitly permitted. Preserve authorised internal records, provenance and history. Previously downloaded copies outside SHARED cannot be recalled.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-019-C08-A01, SH-GEO-FEAT-019-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
SH-GEO-FEAT-020-C01 · Distinguish reported from verified landslides, thermal detections from confirmed fires, forecasts from observed flood extents, suitability scores from legal land-use decisions, proposed from implemented activities, and exploratory from accepted scientific results.
Parent requirement and conditions: Distinguish reported from verified landslides, thermal detections from confirmed fires, forecasts from observed flood extents, suitability scores from legal land-use decisions, proposed from implemented activities, and exploratory from accepted scientific results. Official warnings, regulatory decisions and expert conclusions require their own authority and approval.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-020-C01-A01, SH-GEO-FEAT-020-D01, SC-STATE-VALID, SC-STATE-INVALID
SH-GEO-FEAT-020-C02 · Official warnings, regulatory decisions and expert conclusions require their own authority and approval.
Parent requirement and conditions: Distinguish reported from verified landslides, thermal detections from confirmed fires, forecasts from observed flood extents, suitability scores from legal land-use decisions, proposed from implemented activities, and exploratory from accepted scientific results. Official warnings, regulatory decisions and expert conclusions require their own authority and approval.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: SH-GEO-FEAT-020-C02-A01, SH-GEO-FEAT-020-D01, SC-STATE-VALID, SC-STATE-INVALID
FR094-C01 · SHARED must allow permitted users to select bounded approved templates, fields, filters and aggregations.
Parent requirement and conditions: SHARED must allow permitted users to select bounded approved templates, fields, filters and aggregations. Do not accept raw database commands, scripts or arbitrary executable formulas.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR094-C01-A01, FR094-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-RETRY-SAME, SC-RETRY-CRASH
FR094-C02 · Do not accept raw database commands, scripts or arbitrary executable formulas.
Parent requirement and conditions: SHARED must allow permitted users to select bounded approved templates, fields, filters and aggregations. Do not accept raw database commands, scripts or arbitrary executable formulas.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR094-C02-A01, FR094-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-RETRY-SAME, SC-RETRY-CRASH
FR095-C01 · SHARED must retain source and version, time, scope and reproducible inputs for queries and executions.
Parent requirement and conditions: SHARED must retain source and version, time, scope and reproducible inputs for queries and executions. Export and later reads must recheck permission.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR095-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR095-C02 · Export and later reads must recheck permission.
Parent requirement and conditions: SHARED must retain source and version, time, scope and reproducible inputs for queries and executions. Export and later reads must recheck permission.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR095-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR096-C01 · SHARED must retain a versioned join plan identifying exact input versions, keys, number of matching records, time alignment, meaning of one output row, missing-row policy, purpose and evidence.
Parent requirement and conditions: SHARED must retain a versioned join plan identifying exact input versions, keys, number of matching records, time alignment, meaning of one output row, missing-row policy, purpose and evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR096-C01-A01, FR096-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR097-C01 · SHARED must preserve unmatched rows and mapping or approval checks when joining datasets.
Parent requirement and conditions: SHARED must preserve unmatched rows and mapping or approval checks when joining datasets. Reject duplicate keys, unsupported joins, changed approval state and work beyond limits.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR097-C01-A01, FR097-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID
FR097-C02 · Reject duplicate keys, unsupported joins, changed approval state and work beyond limits.
Parent requirement and conditions: SHARED must preserve unmatched rows and mapping or approval checks when joining datasets. Reject duplicate keys, unsupported joins, changed approval state and work beyond limits.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR097-C02-A01, FR097-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID
FR098-C01 · SHARED must reuse private versioned report definitions and saved report runs, retaining exact source values, units, filters, review and calculation.
Parent requirement and conditions: SHARED must reuse private versioned report definitions and saved report runs, retaining exact source values, units, filters, review and calculation. Editing or refreshing creates a new version or execution.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR098-C01-A01, FR098-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR098-C02 · Editing or refreshing creates a new version or execution.
Parent requirement and conditions: SHARED must reuse private versioned report definitions and saved report runs, retaining exact source values, units, filters, review and calculation. Editing or refreshing creates a new version or execution.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR098-C02-A01, FR098-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR099-C01 · SHARED must use suitable comparisons, date series and distributions with units and source coverage.
Parent requirement and conditions: SHARED must use suitable comparisons, date series and distributions with units and source coverage.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR099-C01-A01, FR099-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR100-C01 · SHARED must retain source and review evidence in supported spreadsheet, CSV, JSON and print outputs.
Parent requirement and conditions: SHARED must retain source and review evidence in supported spreadsheet, CSV, JSON and print outputs. Formal report versions use saved results, list of supporting evidences and reviewed publication.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR100-C01-A01, FR100-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR100-C02 · Formal report versions use saved results, list of supporting evidences and reviewed publication.
Parent requirement and conditions: SHARED must retain source and review evidence in supported spreadsheet, CSV, JSON and print outputs. Formal report versions use saved results, list of supporting evidences and reviewed publication.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR100-C02-A01, FR100-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR101-C01 · SHARED must show each decision question, exact context, required data, method, authority and outcome-monitoring needs.
Parent requirement and conditions: SHARED must show each decision question, exact context, required data, method, authority and outcome-monitoring needs. Missing data, expert decisions and governance approval must have named owners.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR101-C01-A01, FR101-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID
FR101-C02 · Missing data, expert decisions and governance approval must have named owners.
Parent requirement and conditions: SHARED must show each decision question, exact context, required data, method, authority and outcome-monitoring needs. Missing data, expert decisions and governance approval must have named owners.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR101-C02-A01, FR101-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID
FR102-C01 · SHARED must use explicit reviewed weights, best/worst anchors, exact source units and required values in the criteria calculation within defined limits.
Parent requirement and conditions: SHARED must use explicit reviewed weights, best/worst anchors, exact source units and required values in the criteria calculation within defined limits. Missing evidence blocks the score; equal scores keep equal rank.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR102-C01-A01, FR102-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR102-C02 · Missing evidence blocks the score.
Parent requirement and conditions: SHARED must use explicit reviewed weights, best/worst anchors, exact source units and required values in the criteria calculation within defined limits. Missing evidence blocks the score; equal scores keep equal rank.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR102-C02-A01, FR102-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR102-C03 · equal scores keep equal rank.
Parent requirement and conditions: SHARED must use explicit reviewed weights, best/worst anchors, exact source units and required values in the criteria calculation within defined limits. Missing evidence blocks the score; equal scores keep equal rank.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR102-C03-A01, FR102-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR103-C01 · SHARED must check compatible unit, place and period before plan/actual arithmetic and withhold percentage variance when the plan is zero.
Parent requirement and conditions: SHARED must check compatible unit, place and period before plan/actual arithmetic and withhold percentage variance when the plan is zero. Numeric rule checks require explicit reviewed thresholds and output meaning.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR103-C01-A01, FR103-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR103-C02 · Numeric rule checks require explicit reviewed thresholds and output meaning.
Parent requirement and conditions: SHARED must check compatible unit, place and period before plan/actual arithmetic and withhold percentage variance when the plan is zero. Numeric rule checks require explicit reviewed thresholds and output meaning.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR103-C02-A01, FR103-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR104-C01 · SHARED must allow an approved enabled routing policy to create a shared review case with named people, severity and deadline.
Parent requirement and conditions: SHARED must allow an approved enabled routing policy to create a shared review case with named people, severity and deadline. Case creation and result publication must succeed or fail together.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR104-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR104-C02 · Case creation and result publication must succeed or fail together.
Parent requirement and conditions: SHARED must allow an approved enabled routing policy to create a shared review case with named people, severity and deadline. Case creation and result publication must succeed or fail together.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR104-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR105-C01 · SHARED must retain each case's problem, evidence, assignment, options, consultation, recommendation, authority, rationale, actions, outcome verification and closure or reopening history.
Parent requirement and conditions: SHARED must retain each case's problem, evidence, assignment, options, consultation, recommendation, authority, rationale, actions, outcome verification and closure or reopening history.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR105-C01-A01, FR105-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
FR106-C01 · SHARED must use actual permitted records for decision preparation.
Parent requirement and conditions: SHARED must use actual permitted records for decision preparation. When considering which option fits the local circumstances, SHARED must reuse current independently reviewed published knowledge and exact case citations.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR106-C01-A01, FR106-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR106-C02 · When considering which option fits the local circumstances, SHARED must reuse current independently reviewed published knowledge and exact case citations.
Parent requirement and conditions: SHARED must use actual permitted records for decision preparation. When considering which option fits the local circumstances, SHARED must reuse current independently reviewed published knowledge and exact case citations.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR106-C02-A01, FR106-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR107-C01 · SHARED must enforce required independence between decision roles.
Parent requirement and conditions: SHARED must enforce required independence between decision roles. Generic scoring and policy checks must not claim scientific suitability, legal eligibility, entitlement or payment authority.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR107-C01-A01, FR107-D01
FR107-C02 · Generic scoring and policy checks must not claim scientific suitability, legal eligibility, entitlement or payment authority.
Parent requirement and conditions: SHARED must enforce required independence between decision roles. Generic scoring and policy checks must not claim scientific suitability, legal eligibility, entitlement or payment authority.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR107-C02-A01, FR107-D01
FR108-C01 · SHARED must keep project type, funder, lead, partners, objectives, dates, lifecycle state and reporting obligations within permitted scope.
Parent requirement and conditions: SHARED must keep project type, funder, lead, partners, objectives, dates, lifecycle state and reporting obligations within permitted scope.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR108-C01-A01, FR108-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID
FR109-C01 · SHARED must link one project to several domains and places through explicit applicability relationships tied to that project revision.
Parent requirement and conditions: SHARED must link one project to several domains and places through explicit applicability relationships tied to that project revision.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR109-C01-A01, FR109-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
FR110-C01 · SHARED must maintain components, activities, interventions, sites, responsible organizations, schedules and implementation state.
Parent requirement and conditions: SHARED must maintain components, activities, interventions, sites, responsible organizations, schedules and implementation state.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR110-C01-A01, FR110-D01, SC-STATE-VALID, SC-STATE-INVALID
FR111-C01 · SHARED must preserve source and access rules when linking projects or interventions to documents, datasets, indicators, layers, submissions and evidence.
Parent requirement and conditions: SHARED must preserve source and access rules when linking projects or interventions to documents, datasets, indicators, layers, submissions and evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR111-C01-A01, FR111-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR112-C01 · SHARED must retain a reviewed source baseline, original project identifier, baseline date and known quality findings when onboarding an ongoing or completed project.
Parent requirement and conditions: SHARED must retain a reviewed source baseline, original project identifier, baseline date and known quality findings when onboarding an ongoing or completed project. The import must preserve known history without inventing milestones.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR112-C01-A01, FR112-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR112-C02 · The import must preserve known history without inventing milestones.
Parent requirement and conditions: SHARED must retain a reviewed source baseline, original project identifier, baseline date and known quality findings when onboarding an ongoing or completed project. The import must preserve known history without inventing milestones.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR112-C02-A01, FR112-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR113-C01 · SHARED must create linked revisions for material changes to active projects instead of overwriting approved project or domain profiles.
Parent requirement and conditions: SHARED must create linked revisions for material changes to active projects instead of overwriting approved project or domain profiles.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR113-C01-A01, FR113-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR114-C01 · SHARED must use one persisted plan from intake and configuration through review, activation, execution, monitoring, decision, reporting, closure and archive.
Parent requirement and conditions: SHARED must use one persisted plan from intake and configuration through review, activation, execution, monitoring, decision, reporting, closure and archive.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR114-C01-A01, FR114-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR115-C01 · SHARED must distinguish setting up a new project from importing an ongoing or completed project.
Parent requirement and conditions: SHARED must distinguish setting up a new project from importing an ongoing or completed project. Each applicable step must keep status, owner, due date, dependencies, validation and completion evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR115-C01-A01, FR115-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR115-C02 · Each applicable step must keep status, owner, due date, dependencies, validation and completion evidence.
Parent requirement and conditions: SHARED must distinguish setting up a new project from importing an ongoing or completed project. Each applicable step must keep status, owner, due date, dependencies, validation and completion evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR115-C02-A01, FR115-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR116-C01 · SHARED must keep obligation definition, occurrence, fixed submitted version, schema section, artifact and review decision separately linked.
Parent requirement and conditions: SHARED must keep obligation definition, occurrence, fixed submitted version, schema section, artifact and review decision separately linked.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR116-C01-A01, FR116-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR117-C01 · SHARED must support one-time and recurring obligations.
Parent requirement and conditions: SHARED must support one-time and recurring obligations. Generate occurrences repeatably and derive overdue from the actual due date and state.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR117-C01-A01, FR117-D01, SC-STATE-VALID, SC-STATE-INVALID
FR117-C02 · Generate occurrences repeatably and derive overdue from the actual due date and state.
Parent requirement and conditions: SHARED must support one-time and recurring obligations. Generate occurrences repeatably and derive overdue from the actual due date and state.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR117-C02-A01, FR117-D01, SC-STATE-VALID, SC-STATE-INVALID
FR118-C01 · SHARED must record each assignment's responsible organization, group or person, component, domain, geography, dates, dependencies, acceptance criteria, authority and evidence needs.
Parent requirement and conditions: SHARED must record each assignment's responsible organization, group or person, component, domain, geography, dates, dependencies, acceptance criteria, authority and evidence needs.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR118-C01-A01, FR118-D01
FR119-C01 · SHARED must validate against the original form version.
Parent requirement and conditions: SHARED must validate against the original form version. Retain review findings, return reasons, corrected versions and resubmission. Blocking findings must prevent acceptance.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR119-C01-A01, FR119-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR119-C02 · Retain review findings, return reasons, corrected versions and resubmission.
Parent requirement and conditions: SHARED must validate against the original form version. Retain review findings, return reasons, corrected versions and resubmission. Blocking findings must prevent acceptance.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR119-C02-A01, FR119-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR119-C03 · Blocking findings must prevent acceptance.
Parent requirement and conditions: SHARED must validate against the original form version. Retain review findings, return reasons, corrected versions and resubmission. Blocking findings must prevent acceptance.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR119-C03-A01, FR119-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR120-C01 · SHARED must prevent My work and review queues from disclosing differently scoped work through lists, counts, maps, files or exports.
Parent requirement and conditions: SHARED must prevent My work and review queues from disclosing differently scoped work through lists, counts, maps, files or exports.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR120-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR121-C01 · SHARED must use configured reviewer assignments and retained decisions.
Parent requirement and conditions: SHARED must use configured reviewer assignments and retained decisions. Protect high-impact publication, role, geography, taxonomy and import changes with independent approval.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR121-C01-A01, FR121-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION, SC-INTERFACE-BAD
FR121-C02 · Protect high-impact publication, role, geography, taxonomy and import changes with independent approval.
Parent requirement and conditions: SHARED must use configured reviewer assignments and retained decisions. Protect high-impact publication, role, geography, taxonomy and import changes with independent approval.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR121-C02-A01, FR121-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION, SC-INTERFACE-BAD
FR122-C01 · SHARED must link an exact permitted feedback submission to the shared decision case with compatible revision, domain and place.
Parent requirement and conditions: SHARED must link an exact permitted feedback submission to the shared decision case with compatible revision, domain and place. Keep original content, review and later response evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR122-C01-A01, FR122-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR122-C02 · Keep original content, review and later response evidence.
Parent requirement and conditions: SHARED must link an exact permitted feedback submission to the shared decision case with compatible revision, domain and place. Keep original content, review and later response evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR122-C02-A01, FR122-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR123-C01 · SHARED must retain reviewed indicators, baseline, target, period, place, responsibility, sources, calculation, quality and approval for each active project-domain monitoring context.
Parent requirement and conditions: SHARED must retain reviewed indicators, baseline, target, period, place, responsibility, sources, calculation, quality and approval for each active project-domain monitoring context.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR123-C01-A01, FR123-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR124-C01 · SHARED must support unknown or descriptive baselines where permitted, dated targets, denominators, assumptions and verification needs.
Parent requirement and conditions: SHARED must support unknown or descriptive baselines where permitted, dated targets, denominators, assumptions and verification needs. Keep targets separate from observed results.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR124-C01-A01, FR124-D01
FR124-C02 · Keep targets separate from observed results.
Parent requirement and conditions: SHARED must support unknown or descriptive baselines where permitted, dated targets, denominators, assumptions and verification needs. Keep targets separate from observed results.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR124-C02-A01, FR124-D01
FR125-C01 · SHARED must generate monitoring results only through approved versioned calculations.
Parent requirement and conditions: SHARED must generate monitoring results only through approved versioned calculations. Keep exact input and output history, steps, units, parameters, review and execution evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR125-C01-A01, FR125-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR125-C02 · Keep exact input and output history, steps, units, parameters, review and execution evidence.
Parent requirement and conditions: SHARED must generate monitoring results only through approved versioned calculations. Keep exact input and output history, steps, units, parameters, review and execution evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR125-C02-A01, FR125-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR126-C01 · SHARED must reconcile delivery, monitoring, decisions, data, access, knowledge, handover, retention and post-project obligations during required closure.
Parent requirement and conditions: SHARED must reconcile delivery, monitoring, decisions, data, access, knowledge, handover, retention and post-project obligations during required closure.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR126-C01-A01, FR126-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-RETRY-SAME, SC-RETRY-CRASH
FR127-C01 · SHARED must record each closure check's owner, deadline, evidence and independent verification or permitted reasoned waiver.
Parent requirement and conditions: SHARED must record each closure check's owner, deadline, evidence and independent verification or permitted reasoned waiver. Retain unchangeable status history.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR127-C01-A01, FR127-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
FR127-C02 · Retain unchangeable status history.
Parent requirement and conditions: SHARED must record each closure check's owner, deadline, evidence and independent verification or permitted reasoned waiver. Retain unchangeable status history.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR127-C02-A01, FR127-D01, SC-VERSION-STALE, SC-VERSION-CHANGE
FR128-C01 · SHARED must enforce the approved closure plan and frozen list of required closure checks before a project becomes Closed or Archived.
Parent requirement and conditions: SHARED must enforce the approved closure plan and frozen list of required closure checks before a project becomes Closed or Archived. This gate applies through every supported service operation.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR128-C01-A01, FR128-D01
FR128-C02 · This gate applies through every supported service operation.
Parent requirement and conditions: SHARED must enforce the approved closure plan and frozen list of required closure checks before a project becomes Closed or Archived. This gate applies through every supported service operation.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR128-C02-A01, FR128-D01
FR090-C01 · SHARED must extend shared structure or intervention records with asset profiles.
Parent requirement and conditions: SHARED must extend shared structure or intervention records with asset profiles. Keep condition, capacity, custody and directed source-reported connections with evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR090-C01-A01, FR090-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR090-C02 · Keep condition, capacity, custody and directed source-reported connections with evidence.
Parent requirement and conditions: SHARED must extend shared structure or intervention records with asset profiles. Keep condition, capacity, custody and directed source-reported connections with evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR090-C02-A01, FR090-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR091-C01 · SHARED must link asset handover and maintenance responsibilities to the required receiving-institution evidence and shared closure process.
Parent requirement and conditions: SHARED must link asset handover and maintenance responsibilities to the required receiving-institution evidence and shared closure process.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR091-C01-A01, FR091-D01
FR086-C01 · SHARED must extend shared identities with programme participant profiles.
Parent requirement and conditions: SHARED must extend shared identities with programme participant profiles and retain their owner, domain, geography, source and origin. Keep shared departmental accounts separate from individual beneficiaries.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR086-C01-A01, FR086-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR086-C02 · retain their owner, domain, geography, source and origin.
Parent requirement and conditions: SHARED must extend shared identities with programme participant profiles and retain their owner, domain, geography, source and origin. Keep shared departmental accounts separate from individual beneficiaries.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR086-C02-A01, FR086-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR086-C03 · Keep shared departmental accounts separate from individual beneficiaries.
Parent requirement and conditions: SHARED must extend shared identities with programme participant profiles and retain their owner, domain, geography, source and origin. Keep shared departmental accounts separate from individual beneficiaries.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR086-C03-A01, FR086-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR087-C01 · SHARED must retain support episodes with their programme, provider, type, source-reported status and known amounts, currency, quantities and dates.
Parent requirement and conditions: SHARED must retain support episodes with their programme, provider, type, source-reported status and known amounts, currency, quantities and dates. Prior-assistance checks must respect lawful access.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR087-C01-A01, FR087-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR087-C02 · Prior-assistance checks must respect lawful access.
Parent requirement and conditions: SHARED must retain support episodes with their programme, provider, type, source-reported status and known amounts, currency, quantities and dates. Prior-assistance checks must respect lawful access.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR087-C02-A01, FR087-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR088-C01 · SHARED must reuse shared product, production, producer and named buyer-demand records, retaining their source, units, period and place.
Parent requirement and conditions: SHARED must reuse shared product, production, producer and named buyer-demand records, retaining their source, units, period and place.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR088-C01-A01, FR088-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR089-C01 · SHARED must record the definition, period, evidence and denominator for each employment, income, training, women/youth participation or other outcome.
Parent requirement and conditions: SHARED must record the definition, period, evidence and denominator for each employment, income, training, women/youth participation or other outcome. A population count is not programme participation.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR089-C01-A01, FR089-D01
FR089-C02 · A population count is not programme participation.
Parent requirement and conditions: SHARED must record the definition, period, evidence and denominator for each employment, income, training, women/youth participation or other outcome. A population count is not programme participation.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR089-C02-A01, FR089-D01
FR129-C01 · SHARED must keep evidence descriptive information, checksum, classification, version and review/publication state with controlled project, domain and location links.
Parent requirement and conditions: SHARED must keep evidence descriptive information, checksum, classification, version and review/publication state with controlled project, domain and location links.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR129-C01-A01, FR129-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR130-C01 · SHARED must store originals that cannot be changed and controlled previews outside public web folders.
Parent requirement and conditions: SHARED must store originals that cannot be changed and controlled previews outside public web folders. Replacement must create a new version.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR130-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR130-C02 · Replacement must create a new version.
Parent requirement and conditions: SHARED must store originals that cannot be changed and controlled previews outside public web folders. Replacement must create a new version.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR130-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR131-C01 · SHARED must enforce size, type, signature, renamed storage, quarantine and genuine malware checks before publication.
Parent requirement and conditions: SHARED must enforce size, type, signature, renamed storage, quarantine and genuine malware checks before publication. Reauthorize preview, download and export; expire temporary links where relevant.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR131-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR131-C02 · Reauthorize preview, download and export.
Parent requirement and conditions: SHARED must enforce size, type, signature, renamed storage, quarantine and genuine malware checks before publication. Reauthorize preview, download and export; expire temporary links where relevant.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR131-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR131-C03 · expire temporary links where relevant.
Parent requirement and conditions: SHARED must enforce size, type, signature, renamed storage, quarantine and genuine malware checks before publication. Reauthorize preview, download and export; expire temporary links where relevant.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR131-C03-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR132-C01 · SHARED must enforce knowledge authoring, independent review, publication, replacement by a newer version, retention and archive stages.
Parent requirement and conditions: SHARED must enforce knowledge authoring, independent review, publication, replacement by a newer version, retention and archive stages. Keep earlier versions unchanged.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR132-C01-A01, FR132-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR132-C02 · Keep earlier versions unchanged.
Parent requirement and conditions: SHARED must enforce knowledge authoring, independent review, publication, replacement by a newer version, retention and archive stages. Keep earlier versions unchanged.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR132-C02-A01, FR132-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR133-C01 · SHARED must link knowledge to permitted projects, areas, sources, evidence, results, decisions and deliverables.
Parent requirement and conditions: SHARED must link knowledge to permitted projects, areas, sources, evidence, results, decisions and deliverables. Recheck restricted or withdrawn citations without leaking descriptive information.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR133-C01-A01, FR133-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR133-C02 · Recheck restricted or withdrawn citations without leaking descriptive information.
Parent requirement and conditions: SHARED must link knowledge to permitted projects, areas, sources, evidence, results, decisions and deliverables. Recheck restricted or withdrawn citations without leaking descriptive information.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR133-C02-A01, FR133-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR134-C01 · SHARED must let public readers find eligible local information, options, opportunities and project activities without an account.
Parent requirement and conditions: SHARED must let public readers find eligible local information, options, opportunities and project activities without an account. Signed-in readers must retain an uncomplicated public view.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR134-C01-A01, FR134-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR134-C02 · Signed-in readers must retain an uncomplicated public view.
Parent requirement and conditions: SHARED must let public readers find eligible local information, options, opportunities and project activities without an account. Signed-in readers must retain an uncomplicated public view.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR134-C02-A01, FR134-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR135-C01 · SHARED must keep protected feedback separate from public grievances.
Parent requirement and conditions: SHARED must keep protected feedback separate from public grievances. Public activation needs a recorded policy covering receiver, deadlines, independent appeal, privacy, safeguarding and abuse controls.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR135-C01-A01, FR135-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR135-C02 · Public activation needs a recorded policy covering receiver, deadlines, independent appeal, privacy, safeguarding and abuse controls.
Parent requirement and conditions: SHARED must keep protected feedback separate from public grievances. Public activation needs a recorded policy covering receiver, deadlines, independent appeal, privacy, safeguarding and abuse controls.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR135-C02-A01, FR135-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-PUBLIC-ALLOW, SC-PUBLIC-WITHDRAW, SC-PUBLIC-OLDVERSION
FR082-C01 · SHARED must retain product, quantity, unit, dates, currency, source and scope for harvest batches, buyers, sales and recorded sale-payment evidence.
Parent requirement and conditions: SHARED must retain product, quantity, unit, dates, currency, source and scope for harvest batches, buyers, sales and recorded sale-payment evidence. Recording evidence is not executing a payment.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR082-C01-A01, FR082-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR082-C02 · Recording evidence is not executing a payment.
Parent requirement and conditions: SHARED must retain product, quantity, unit, dates, currency, source and scope for harvest batches, buyers, sales and recorded sale-payment evidence. Recording evidence is not executing a payment.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR082-C02-A01, FR082-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR083-C01 · SHARED must retain a source-supported origin assertion for the particular record and expire the assertion when the supporting facts change.
Parent requirement and conditions: SHARED must retain a source-supported origin assertion for the particular record and expire the assertion when the supporting facts change. Complete unknown currency through authorized evidence without changing amounts or an established currency silently.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR083-C01-A01, FR083-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
FR083-C02 · Complete unknown currency through authorized evidence without changing amounts or an established currency silently.
Parent requirement and conditions: SHARED must retain a source-supported origin assertion for the particular record and expire the assertion when the supporting facts change. Complete unknown currency through authorized evidence without changing amounts or an established currency silently.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR083-C02-A01, FR083-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
FR084-C01 · SHARED must retain exact product, unit, origin, periods, row versions and comparison time when comparing production and demand.
Parent requirement and conditions: SHARED must retain exact product, unit, origin, periods, row versions and comparison time when comparing production and demand. Different periods must not produce a misleading quantity difference.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR084-C01-A01, FR084-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR084-C02 · Different periods must not produce a misleading quantity difference.
Parent requirement and conditions: SHARED must retain exact product, unit, origin, periods, row versions and comparison time when comparing production and demand. Different periods must not produce a misleading quantity difference.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR084-C02-A01, FR084-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE
FR085-C01 · SHARED must use reviewed formula versions and exact compatible inputs for seasonal production, cost, revenue, margin and break-even outputs.
Parent requirement and conditions: SHARED must use reviewed formula versions and exact compatible inputs for seasonal production, cost, revenue, margin and break-even outputs. Unknown costs, yield assumptions, currencies and season definitions must block the affected result or appear as explicitly incomplete.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR085-C01-A01, FR085-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR085-C02 · Unknown costs, yield assumptions, currencies and season definitions must block the affected result or appear as explicitly incomplete.
Parent requirement and conditions: SHARED must use reviewed formula versions and exact compatible inputs for seasonal production, cost, revenue, margin and break-even outputs. Unknown costs, yield assumptions, currencies and season definitions must block the affected result or appear as explicitly incomplete.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR085-C02-A01, FR085-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR092-C01 · SHARED must retain the owner and authority of PES schemes, agreements, service verification and source-reported payment-stage evidence.
Parent requirement and conditions: SHARED must retain the owner and authority of PES schemes, agreements, service verification and source-reported payment-stage evidence. Missing rates, eligibility, appeals or legal approval must not be invented.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR092-C01-A01, FR092-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR092-C02 · Missing rates, eligibility, appeals or legal approval must not be invented.
Parent requirement and conditions: SHARED must retain the owner and authority of PES schemes, agreements, service verification and source-reported payment-stage evidence. Missing rates, eligibility, appeals or legal approval must not be invented.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR092-C02-A01, FR092-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR093-C01 · SHARED must connect permitted support, product, asset, market, outcome and evidence records in analysis while preserving source versions and original scope.
Parent requirement and conditions: SHARED must connect permitted support, product, asset, market, outcome and evidence records in analysis while preserving source versions and original scope.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR093-C01-A01, FR093-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
FR136-C01 · SHARED must provide a web application that uses the published service contracts, secure server-side sessions, anti-forgery protection and secure cookies.
Parent requirement and conditions: SHARED must provide a web application that uses the published service contracts, secure server-side sessions, anti-forgery protection and secure cookies. It must never access database tables directly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR136-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR136-C02 · It must never access database tables directly.
Parent requirement and conditions: SHARED must provide a web application that uses the published service contracts, secure server-side sessions, anti-forgery protection and secure cookies. It must never access database tables directly.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR136-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR137-C01 · SHARED must use guided steps, searchable choices, progressive details and clear loading, empty, error and denied states.
Parent requirement and conditions: SHARED must use guided steps, searchable choices, progressive details and clear loading, empty, error and denied states. Validate responsive, keyboard and accessibility behaviour on the agreed matrix.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR137-C01-A01, FR137-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID
FR137-C02 · Validate responsive, keyboard and accessibility behaviour on the agreed matrix.
Parent requirement and conditions: SHARED must use guided steps, searchable choices, progressive details and clear loading, empty, error and denied states. Validate responsive, keyboard and accessibility behaviour on the agreed matrix.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR137-C02-A01, FR137-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID
FR138-C01 · Obtain approved choices from authorised reference-data interfaces.
Parent requirement and conditions: SHARED must obtain approved choices from authorised API reference data. It must support English, Sinhala and Tamil resources for the agreed delivery scope. Client-appointed reviewers must accept terminology and translations before release.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR138-C01-A01, FR138-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR138-C02 · Support English resources in the agreed delivery scope.
Parent requirement and conditions: SHARED must obtain approved choices from authorised API reference data. It must support English, Sinhala and Tamil resources for the agreed delivery scope. Client-appointed reviewers must accept terminology and translations before release.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR138-C02-A01, FR138-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR138-C03 · Support Sinhala resources in the agreed delivery scope.
Parent requirement and conditions: SHARED must obtain approved choices from authorised API reference data. It must support English, Sinhala and Tamil resources for the agreed delivery scope. Client-appointed reviewers must accept terminology and translations before release.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR138-C03-A01, FR138-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR138-C04 · Support Tamil resources in the agreed delivery scope.
Parent requirement and conditions: SHARED must obtain approved choices from authorised API reference data. It must support English, Sinhala and Tamil resources for the agreed delivery scope. Client-appointed reviewers must accept terminology and translations before release.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR138-C04-A01, FR138-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR138-C05 · Require client-appointed terminology and translation acceptance before release.
Parent requirement and conditions: SHARED must obtain approved choices from authorised API reference data. It must support English, Sinhala and Tamil resources for the agreed delivery scope. Client-appointed reviewers must accept terminology and translations before release.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR138-C05-A01, FR138-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR139-C01 · SHARED must use environment-safe configuration and the same authenticated service interfaces across approved access channels.
Parent requirement and conditions: SHARED must use environment-safe configuration and the same authenticated service interfaces across approved access channels. Each channel must protect credentials and session material using approved secure facilities and enforce rotation, revocation, expiry and logout. An additional field-access channel is a proposed option under C01, C06 and C07, not an accepted first-release commitment.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR139-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR139-C02 · Each channel must protect credentials and session material using approved secure facilities.
Parent requirement and conditions: SHARED must use environment-safe configuration and the same authenticated service interfaces across approved access channels. Each channel must protect credentials and session material using approved secure facilities and enforce rotation, revocation, expiry and logout. An additional field-access channel is a proposed option under C01, C06 and C07, not an accepted first-release commitment.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR139-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR139-C03 · enforce rotation, revocation, expiry and logout.
Parent requirement and conditions: SHARED must use environment-safe configuration and the same authenticated service interfaces across approved access channels. Each channel must protect credentials and session material using approved secure facilities and enforce rotation, revocation, expiry and logout. An additional field-access channel is a proposed option under C01, C06 and C07, not an accepted first-release commitment.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR139-C03-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR139-C04 · An additional field-access channel is a proposed option under C01, C06 and C07, not an accepted first-release commitment.
Parent requirement and conditions: SHARED must use environment-safe configuration and the same authenticated service interfaces across approved access channels. Each channel must protect credentials and session material using approved secure facilities and enforce rotation, revocation, expiry and logout. An additional field-access channel is a proposed option under C01, C06 and C07, not an accepted first-release commitment.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR139-C04-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR140-C01 · Through the responsive core interface, SHARED must allow permitted users to browse assigned projects, domains, places and maps and capture authorised location, source, accuracy, observation time and evidence.
Parent requirement and conditions: Through the responsive core interface, SHARED must allow permitted users to browse assigned projects, domains, places and maps and capture authorised location, source, accuracy, observation time and evidence. An additional field-access channel or local draft-storage capability is conditional on C01, C06 and C07. When local drafts are permitted, protect them under the approved encryption, retention and privacy rules.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR140-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR140-C02 · An additional field-access channel or local draft-storage capability is conditional on C01, C06 and C07.
Parent requirement and conditions: Through the responsive core interface, SHARED must allow permitted users to browse assigned projects, domains, places and maps and capture authorised location, source, accuracy, observation time and evidence. An additional field-access channel or local draft-storage capability is conditional on C01, C06 and C07. When local drafts are permitted, protect them under the approved encryption, retention and privacy rules.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR140-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR140-C03 · When local drafts are permitted, protect them under the approved encryption, retention and privacy rules.
Parent requirement and conditions: Through the responsive core interface, SHARED must allow permitted users to browse assigned projects, domains, places and maps and capture authorised location, source, accuracy, observation time and evidence. An additional field-access channel or local draft-storage capability is conditional on C01, C06 and C07. When local drafts are permitted, protect them under the approved encryption, retention and privacy rules.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR140-C03-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR141-C01 · If offline operation is selected under C01, C06 and C07, SHARED must protect downloaded authorised assignments, local drafts and evidence under the agreed retention and privacy rules.
Parent requirement and conditions: If offline operation is selected under C01, C06 and C07, SHARED must protect downloaded authorised assignments, local drafts and evidence under the agreed retention and privacy rules. Show pending, sending, received, rejected and conflict states. Synchronise through the common authenticated service interfaces using stable retry identifiers. Offline operation remains a proposed option until the client accepts its scope.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR141-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR141-C02 · Show pending, sending, received, rejected and conflict states.
Parent requirement and conditions: If offline operation is selected under C01, C06 and C07, SHARED must protect downloaded authorised assignments, local drafts and evidence under the agreed retention and privacy rules. Show pending, sending, received, rejected and conflict states. Synchronise through the common authenticated service interfaces using stable retry identifiers. Offline operation remains a proposed option until the client accepts its scope.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR141-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR141-C03 · Synchronise through the common authenticated service interfaces using stable retry identifiers.
Parent requirement and conditions: If offline operation is selected under C01, C06 and C07, SHARED must protect downloaded authorised assignments, local drafts and evidence under the agreed retention and privacy rules. Show pending, sending, received, rejected and conflict states. Synchronise through the common authenticated service interfaces using stable retry identifiers. Offline operation remains a proposed option until the client accepts its scope.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR141-C03-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR141-C04 · Offline operation remains a proposed option until the client accepts its scope.
Parent requirement and conditions: If offline operation is selected under C01, C06 and C07, SHARED must protect downloaded authorised assignments, local drafts and evidence under the agreed retention and privacy rules. Show pending, sending, received, rejected and conflict states. Synchronise through the common authenticated service interfaces using stable retry identifiers. Offline operation remains a proposed option until the client accepts its scope.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR141-C04-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-STATE-VALID, SC-STATE-INVALID, SC-RETRY-SAME, SC-RETRY-CRASH, SC-INTERFACE-BAD
FR142-C01 · SHARED must retain a clear system explanation and role-based user guidance linked to the relevant permitted workflow.
Parent requirement and conditions: SHARED must retain a clear system explanation and role-based user guidance linked to the relevant permitted workflow. The prototype presentation and diagrams support this explanation. A demonstration link does not grant access or establish operational acceptance.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR142-C01-A01, FR142-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR142-C02 · The prototype presentation and diagrams support this explanation.
Parent requirement and conditions: SHARED must retain a clear system explanation and role-based user guidance linked to the relevant permitted workflow. The prototype presentation and diagrams support this explanation. A demonstration link does not grant access or establish operational acceptance.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR142-C02-A01, FR142-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR142-C03 · A demonstration link does not grant access or establish operational acceptance.
Parent requirement and conditions: SHARED must retain a clear system explanation and role-based user guidance linked to the relevant permitted workflow. The prototype presentation and diagrams support this explanation. A demonstration link does not grant access or establish operational acceptance.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR142-C03-A01, FR142-D01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR143-C01 · SHARED must use versioned API routes and explicit request/response contracts with an accurate API description.
Parent requirement and conditions: SHARED must use versioned API routes and explicit request/response contracts with an accurate API description. Reject unsupported request properties.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR143-C01-A01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR143-C02 · Reject unsupported request properties.
Parent requirement and conditions: SHARED must use versioned API routes and explicit request/response contracts with an accurate API description. Reject unsupported request properties.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR143-C02-A01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
FR144-C01 · SHARED must return consistent safe errors without internal database commands, stack traces or secrets.
Parent requirement and conditions: SHARED must return consistent safe errors without internal database commands, stack traces or secrets. Lists must use deterministic paging, limits, cancellation and timeouts.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR144-C01-A01, FR144-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-RETRY-SAME, SC-RETRY-CRASH
FR144-C02 · Lists must use deterministic paging, limits, cancellation and timeouts.
Parent requirement and conditions: SHARED must return consistent safe errors without internal database commands, stack traces or secrets. Lists must use deterministic paging, limits, cancellation and timeouts.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR144-C02-A01, FR144-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-RETRY-SAME, SC-RETRY-CRASH
FR145-C01 · Use request references, expected-version checks and stable retry identifiers.
Parent requirement and conditions: Use request references, expected-version checks and stable retry identifiers. Limit retries so repeated failures do not overload the service. Health checks must use approved service operations.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR145-C01-A01, FR145-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR145-C02 · Limit retries so repeated failures do not overload the service.
Parent requirement and conditions: Use request references, expected-version checks and stable retry identifiers. Limit retries so repeated failures do not overload the service. Health checks must use approved service operations.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR145-C02-A01, FR145-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR145-C03 · Health checks must use approved service operations.
Parent requirement and conditions: Use request references, expected-version checks and stable retry identifiers. Limit retries so repeated failures do not overload the service. Health checks must use approved service operations.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR145-C03-A01, FR145-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR146-C01 · Apply HTTPS at the service boundary.
Parent requirement and conditions: SHARED must use HTTPS, secure headers, approved origins, rate limits, input checks and endpoint plus permission checks for the requested record.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR146-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR146-C02 · Apply secure headers at the service boundary.
Parent requirement and conditions: SHARED must use HTTPS, secure headers, approved origins, rate limits, input checks and endpoint plus permission checks for the requested record.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR146-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR146-C03 · Apply approved origins at the service boundary.
Parent requirement and conditions: SHARED must use HTTPS, secure headers, approved origins, rate limits, input checks and endpoint plus permission checks for the requested record.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR146-C03-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR146-C04 · Apply rate limits at the service boundary.
Parent requirement and conditions: SHARED must use HTTPS, secure headers, approved origins, rate limits, input checks and endpoint plus permission checks for the requested record.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR146-C04-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR146-C05 · Apply input checks at the service boundary.
Parent requirement and conditions: SHARED must use HTTPS, secure headers, approved origins, rate limits, input checks and endpoint plus permission checks for the requested record.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR146-C05-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR146-C06 · Check endpoint permission.
Parent requirement and conditions: SHARED must use HTTPS, secure headers, approved origins, rate limits, input checks and endpoint plus permission checks for the requested record.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR146-C06-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR146-C07 · Check permission for the requested record.
Parent requirement and conditions: SHARED must use HTTPS, secure headers, approved origins, rate limits, input checks and endpoint plus permission checks for the requested record.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR146-C07-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR155-C01 · SHARED must keep user-interface responsibilities separate from authenticated application services, shared business rules and controlled data access.
Parent requirement and conditions: SHARED must keep user-interface responsibilities separate from authenticated application services, shared business rules and controlled data access. Clients must not access data-store tables directly. Protect configuration, files and process permissions. A separate deployment or hosting topology is a proposed option under C07; select it only after reviewing isolation, operations, recovery, cost and portability.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR155-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR155-C02 · Clients must not access data-store tables directly.
Parent requirement and conditions: SHARED must keep user-interface responsibilities separate from authenticated application services, shared business rules and controlled data access. Clients must not access data-store tables directly. Protect configuration, files and process permissions. A separate deployment or hosting topology is a proposed option under C07; select it only after reviewing isolation, operations, recovery, cost and portability.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR155-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR155-C03 · Protect configuration, files and process permissions.
Parent requirement and conditions: SHARED must keep user-interface responsibilities separate from authenticated application services, shared business rules and controlled data access. Clients must not access data-store tables directly. Protect configuration, files and process permissions. A separate deployment or hosting topology is a proposed option under C07; select it only after reviewing isolation, operations, recovery, cost and portability.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR155-C03-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR155-C04 · A separate deployment or hosting topology is a proposed option under C07.
Parent requirement and conditions: SHARED must keep user-interface responsibilities separate from authenticated application services, shared business rules and controlled data access. Clients must not access data-store tables directly. Protect configuration, files and process permissions. A separate deployment or hosting topology is a proposed option under C07; select it only after reviewing isolation, operations, recovery, cost and portability.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR155-C04-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR155-C05 · select it only after reviewing isolation, operations, recovery, cost and portability.
Parent requirement and conditions: SHARED must keep user-interface responsibilities separate from authenticated application services, shared business rules and controlled data access. Clients must not access data-store tables directly. Protect configuration, files and process permissions. A separate deployment or hosting topology is a proposed option under C07; select it only after reviewing isolation, operations, recovery, cost and portability.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR155-C05-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR147-C01 · SHARED must perform runtime data access through a controlled server-side data access layer and approved operations, including identity and health checks.
Parent requirement and conditions: SHARED must perform runtime data access through a controlled server-side data access layer and approved operations, including identity and health checks. Runtime principals receive only the necessary permissions. Clients never access database tables. The selected database plan must specify the operation catalogue and enforcement evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR147-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR147-C02 · Runtime principals receive only the necessary permissions.
Parent requirement and conditions: SHARED must perform runtime data access through a controlled server-side data access layer and approved operations, including identity and health checks. Runtime principals receive only the necessary permissions. Clients never access database tables. The selected database plan must specify the operation catalogue and enforcement evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR147-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR147-C03 · Clients never access database tables.
Parent requirement and conditions: SHARED must perform runtime data access through a controlled server-side data access layer and approved operations, including identity and health checks. Runtime principals receive only the necessary permissions. Clients never access database tables. The selected database plan must specify the operation catalogue and enforcement evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR147-C03-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR147-C04 · The selected database plan must specify the operation catalogue and enforcement evidence.
Parent requirement and conditions: SHARED must perform runtime data access through a controlled server-side data access layer and approved operations, including identity and health checks. Runtime principals receive only the necessary permissions. Clients never access database tables. The selected database plan must specify the operation catalogue and enforcement evidence.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR147-C04-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR148-C01 · SHARED must record significant actor, action, resource, scope, result, reason, standard time and request reference.
Parent requirement and conditions: SHARED must record significant actor, action, resource, scope, result, reason, standard time and request reference. Trace published data back through source, validation and review.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR148-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
FR148-C02 · Trace published data back through source, validation and review.
Parent requirement and conditions: SHARED must record significant actor, action, resource, scope, result, reason, standard time and request reference. Trace published data back through source, validation and review.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR148-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID, SC-INTERFACE-BAD
NFR01-C01 · The service shall achieve at least 99 percent availability.
Parent requirement and conditions: The service shall achieve at least 99 percent availability. This is the TOR minimum. Proposed measurement is a calendar month of agreed service minutes, including planned maintenance until an exclusion policy is approved.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR01-C01-A01
NFR01-C02 · This is the TOR minimum.
Parent requirement and conditions: The service shall achieve at least 99 percent availability. This is the TOR minimum. Proposed measurement is a calendar month of agreed service minutes, including planned maintenance until an exclusion policy is approved.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR01-C02-A01
NFR01-C03 · Proposed measurement is a calendar month of agreed service minutes, including planned maintenance until an exclusion policy is approved.
Parent requirement and conditions: The service shall achieve at least 99 percent availability. This is the TOR minimum. Proposed measurement is a calendar month of agreed service minutes, including planned maintenance until an exclusion policy is approved.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR01-C03-A01
NFR02-C01 · Proposed target: 100 concurrent authenticated users.
Parent requirement and conditions: Proposed target: 100 concurrent authenticated users; standard bounded API reads p95 at most 750 ms and p99 at most 1.5 seconds; error rate below 0.5 percent.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR02-C01-A01, SC-INTERFACE-BAD
NFR02-C02 · standard bounded API reads p95 at most 750 ms and p99 at most 1.5 seconds.
Parent requirement and conditions: Proposed target: 100 concurrent authenticated users; standard bounded API reads p95 at most 750 ms and p99 at most 1.5 seconds; error rate below 0.5 percent.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR02-C02-A01, SC-INTERFACE-BAD
NFR02-C03 · error rate below 0.5 percent.
Parent requirement and conditions: Proposed target: 100 concurrent authenticated users; standard bounded API reads p95 at most 750 ms and p99 at most 1.5 seconds; error rate below 0.5 percent.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR02-C03-A01, SC-INTERFACE-BAD
NFR03-C01 · Proposed target: bounded spatial queries p95 at most 2 seconds and p99 at most 4 seconds.
Parent requirement and conditions: Proposed target: bounded spatial queries p95 at most 2 seconds and p99 at most 4 seconds.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR03-C01-A01
NFR04-C01 · Proposed sizing: 250 organisations and one million vector features at the agreed workload.
Parent requirement and conditions: Proposed sizing: 250 organisations and one million vector features at the agreed workload. Test twice the interactive load for controlled saturation.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR04-C01-A01
NFR04-C02 · Test twice the interactive load for controlled saturation.
Parent requirement and conditions: Proposed sizing: 250 organisations and one million vector features at the agreed workload. Test twice the interactive load for controlled saturation.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR04-C02-A01
NFR05-C01 · Proposed profile: 1.5 Mbps down, 750 Kbps up, 300 ms round trip and 1 percent packet loss.
Parent requirement and conditions: Proposed profile: 1.5 Mbps down, 750 Kbps up, 300 ms round trip and 1 percent packet loss. Essential initial transfer at most 1.5 MiB compressed. The system shall support mobile-compatible use of the agreed core journeys on client-agreed devices.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR05-C01-A01, SC-INTERFACE-BAD
NFR05-C02 · Essential initial transfer at most 1.5 MiB compressed.
Parent requirement and conditions: Proposed profile: 1.5 Mbps down, 750 Kbps up, 300 ms round trip and 1 percent packet loss. Essential initial transfer at most 1.5 MiB compressed. The system shall support mobile-compatible use of the agreed core journeys on client-agreed devices.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR05-C02-A01, SC-INTERFACE-BAD
NFR05-C03 · The system shall support mobile-compatible use of the agreed core journeys on client-agreed devices.
Parent requirement and conditions: Proposed profile: 1.5 Mbps down, 750 Kbps up, 300 ms round trip and 1 percent packet loss. Essential initial transfer at most 1.5 MiB compressed. The system shall support mobile-compatible use of the agreed core journeys on client-agreed devices.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR05-C03-A01, SC-INTERFACE-BAD
NFR06-C01 · Proposed web target is WCAG 2.2 AA.
Parent requirement and conditions: Proposed web target is WCAG 2.2 AA. Provide keyboard operation, visible focus, labelled controls, readable error messages, text alternatives, accessible tables and text scaling. English, Sinhala and Tamil coverage requires client agreement.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR06-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-RETRY-SAME, SC-RETRY-CRASH
NFR06-C02 · Provide keyboard operation, visible focus, labelled controls, readable error messages, text alternatives, accessible tables and text scaling.
Parent requirement and conditions: Proposed web target is WCAG 2.2 AA. Provide keyboard operation, visible focus, labelled controls, readable error messages, text alternatives, accessible tables and text scaling. English, Sinhala and Tamil coverage requires client agreement.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR06-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-RETRY-SAME, SC-RETRY-CRASH
NFR06-C03 · English, Sinhala and Tamil coverage requires client agreement.
Parent requirement and conditions: Proposed web target is WCAG 2.2 AA. Provide keyboard operation, visible focus, labelled controls, readable error messages, text alternatives, accessible tables and text scaling. English, Sinhala and Tamil coverage requires client agreement.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR06-C03-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-RETRY-SAME, SC-RETRY-CRASH
NFR07-C01 · Use threat modelling and an agreed OWASP ASVS control set, proposed Level 2.
Parent requirement and conditions: Use threat modelling and an agreed OWASP ASVS control set, proposed Level 2. Protect sessions, inputs, files, exports, transport and secrets.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR07-C01-A01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
NFR07-C02 · Protect sessions, inputs, files, exports, transport and secrets.
Parent requirement and conditions: Use threat modelling and an agreed OWASP ASVS control set, proposed Level 2. Protect sessions, inputs, files, exports, transport and secrets.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR07-C02-A01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
NFR08-C01 · Collect only information needed for an approved purpose.
Parent requirement and conditions: Collect only information needed for an approved purpose. Apply classification, disclosure limits, retention and rights handling to originals, results, exports and backups.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR08-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
NFR08-C02 · Apply classification, disclosure limits, retention and rights handling to originals, results, exports and backups.
Parent requirement and conditions: Collect only information needed for an approved purpose. Apply classification, disclosure limits, retention and rights handling to originals, results, exports and backups.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR08-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
NFR09-C01 · Proposed recovery point objective is 24 hours and recovery time objective is 8 hours.
Parent requirement and conditions: Proposed recovery point objective is 24 hours and recovery time objective is 8 hours. Include database, protected files, configuration, keys and spatial resources.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR09-C01-A01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
NFR09-C02 · Include database, protected files, configuration, keys and spatial resources.
Parent requirement and conditions: Proposed recovery point objective is 24 hours and recovery time objective is 8 hours. Include database, protected files, configuration, keys and spatial resources.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR09-C02-A01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
NFR10-C01 · Commands shall use expected versions and safe retry references.
Parent requirement and conditions: Commands shall use expected versions and safe retry references. Save a business change and its delivery request reliably together.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR10-C01-A01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
NFR10-C02 · Save a business change and its delivery request reliably together.
Parent requirement and conditions: Commands shall use expected versions and safe retry references. Save a business change and its delivery request reliably together.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR10-C02-A01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
NFR11-C01 · Publish versioned API and data contracts.
Parent requirement and conditions: Publish versioned API and data contracts. Declare supported geospatial protocols, encodings, units, coordinate systems and export formats.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR11-C01-A01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
NFR11-C02 · Declare supported geospatial protocols, encodings, units, coordinate systems and export formats.
Parent requirement and conditions: Publish versioned API and data contracts. Declare supported geospatial protocols, encodings, units, coordinate systems and export formats.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR11-C02-A01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
NFR12-C01 · Keep business definitions configurable, modules separated and dependencies supported.
Parent requirement and conditions: Keep business definitions configurable, modules separated and dependencies supported. Supply reproducible builds, migrations, operation contracts and complete export.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR12-C01-A01, SC-INTERFACE-BAD
NFR12-C02 · Supply reproducible builds, migrations, operation contracts and complete export.
Parent requirement and conditions: Keep business definitions configurable, modules separated and dependencies supported. Supply reproducible builds, migrations, operation contracts and complete export.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR12-C02-A01, SC-INTERFACE-BAD
NFR13-C01 · Retain protected business audit separately from redacted diagnostics.
Parent requirement and conditions: Retain protected business audit separately from redacted diagnostics. Proposed correlation target is at least 99 percent of API requests; significant events queryable within five minutes.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR13-C01-A01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
NFR13-C02 · Proposed correlation target is at least 99 percent of API requests.
Parent requirement and conditions: Retain protected business audit separately from redacted diagnostics. Proposed correlation target is at least 99 percent of API requests; significant events queryable within five minutes.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR13-C02-A01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
NFR13-C03 · significant events queryable within five minutes.
Parent requirement and conditions: Retain protected business audit separately from redacted diagnostics. Proposed correlation target is at least 99 percent of API requests; significant events queryable within five minutes.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR13-C03-A01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-INTERFACE-BAD
NFR14-C01 · Name the service owner, support levels, escalation, funding, renewal obligations and patch responsibility before operational acceptance.
Parent requirement and conditions: Name the service owner, support levels, escalation, funding, renewal obligations and patch responsibility before operational acceptance.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: NFR14-C01-A01
FR149-C01 · SHARED must protect private people and sensitive locations from disclosure through search, counts and exports.
Parent requirement and conditions: SHARED must protect private people and sensitive locations from disclosure through search, counts and exports. If an action creates a notification, save the action and delivery request reliably together. Retry delivery without duplicating the message.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR149-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-RETRY-SAME, SC-RETRY-CRASH
FR149-C02 · If an action creates a notification, save the action and delivery request reliably together.
Parent requirement and conditions: SHARED must protect private people and sensitive locations from disclosure through search, counts and exports. If an action creates a notification, save the action and delivery request reliably together. Retry delivery without duplicating the message.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR149-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-RETRY-SAME, SC-RETRY-CRASH
FR149-C03 · Retry delivery without duplicating the message.
Parent requirement and conditions: SHARED must protect private people and sensitive locations from disclosure through search, counts and exports. If an action creates a notification, save the action and delivery request reliably together. Retry delivery without duplicating the message.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR149-C03-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-RETRY-SAME, SC-RETRY-CRASH
FR151-C01 · SHARED must separate development, test, staging and production configuration and inject secrets through protected settings.
Parent requirement and conditions: SHARED must separate development, test, staging and production configuration and inject secrets through protected settings. Do not publish credentials or private data in code, documents, logs or exports.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR151-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR151-C02 · Do not publish credentials or private data in code, documents, logs or exports.
Parent requirement and conditions: SHARED must separate development, test, staging and production configuration and inject secrets through protected settings. Do not publish credentials or private data in code, documents, logs or exports.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR151-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS
FR152-C01 · SHARED must monitor service availability, failures and background processing.
Parent requirement and conditions: SHARED must monitor service availability, failures and background processing. Retain safe diagnostic details and a request reference so an authorised operator can investigate an error. Health responses and logs must not expose credentials, personal records or original source content.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR152-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
FR152-C02 · Retain safe diagnostic details and a request reference so an authorised operator can investigate an error.
Parent requirement and conditions: SHARED must monitor service availability, failures and background processing. Retain safe diagnostic details and a request reference so an authorised operator can investigate an error. Health responses and logs must not expose credentials, personal records or original source content.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR152-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
FR152-C03 · Health responses and logs must not expose credentials, personal records or original source content.
Parent requirement and conditions: SHARED must monitor service availability, failures and background processing. Retain safe diagnostic details and a request reference so an authorised operator can investigate an error. Health responses and logs must not expose credentials, personal records or original source content.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR152-C03-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-VERSION-STALE, SC-VERSION-CHANGE
FR153-C01 · SHARED must support reviewed procedures for deployment, migration, rollback or forward repair, credential rotation, incidents and continuity.
Parent requirement and conditions: SHARED must support reviewed procedures for deployment, migration, rollback or forward repair, credential rotation, incidents and continuity. Do not upgrade the database at application startup.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR153-C01-A01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR153-C02 · Do not upgrade the database at application startup.
Parent requirement and conditions: SHARED must support reviewed procedures for deployment, migration, rollback or forward repair, credential rotation, incidents and continuity. Do not upgrade the database at application startup.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR153-C02-A01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-STATE-VALID, SC-STATE-INVALID
FR154-C01 · SHARED must back up the database and protected files under agreed security and retention rules.
Parent requirement and conditions: SHARED must back up the database and protected files under agreed security and retention rules. Confirm recovery targets through an authorized restore exercise, not backup creation alone.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR154-C01-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR154-C02 · Confirm recovery targets through an authorized restore exercise, not backup creation alone.
Parent requirement and conditions: SHARED must back up the database and protected files under agreed security and retention rules. Confirm recovery targets through an authorized restore exercise, not backup creation alone.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR154-C02-A01, SC-AUTH-ALLOW, SC-AUTH-DENY, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-INTERFACE-BAD
FR150-C01 · SHARED must keep business settings editable and dated.
Parent requirement and conditions: SHARED must keep business settings editable and dated. Register proposed products before claiming delivery. Link requirements to design, work, implementation, tests and evidence, with controlled change history.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR150-C01-A01, FR150-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR150-C02 · Register proposed products before claiming delivery.
Parent requirement and conditions: SHARED must keep business settings editable and dated. Register proposed products before claiming delivery. Link requirements to design, work, implementation, tests and evidence, with controlled change history.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR150-C02-A01, FR150-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR150-C03 · Link requirements to design, work, implementation, tests and evidence, with controlled change history.
Parent requirement and conditions: SHARED must keep business settings editable and dated. Register proposed products before claiming delivery. Link requirements to design, work, implementation, tests and evidence, with controlled change history.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR150-C03-A01, FR150-D01, SC-VERSION-STALE, SC-VERSION-CHANGE, SC-RETRY-SAME, SC-RETRY-CRASH
FR156-C01 · SHARED must track unfinished software separately from missing data, expert decisions and governance approval.
Parent requirement and conditions: SHARED must track unfinished software separately from missing data, expert decisions and governance approval.
Evidence needed: Future service acceptance
Decision status: Pending in Institution review only
Cases: FR156-C01-A01, FR156-D01, SC-DATA-VALID, SC-DATA-INVALID, SC-DATA-MISSING, SC-DATA-ZERO-FALSE, SC-DATA-BOUNDS, SC-STATE-VALID, SC-STATE-INVALID
Case definitions
Each shared case is defined once and linked from its affected clauses.
FR029-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE; owner=SYN-ORG-A.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 with owner and all other declared synthetic catalogue metadata.; Read the exact source/dataset version detail and compare owner to the submitted value.; Revise owner under v2 without overwriting v1; reopen both versions.; Remove or restrict the referenced metadata/source grant and verify honest missing/access status under its policy.
Expected result: Retain owner unchanged on the correct version, with owner/custodian distinctions and history. Missing or unapproved metadata is explicit; it does not become approved rights or an observation.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR029-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE; custodian=SYN-ORG-B.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 with custodian and all other declared synthetic catalogue metadata.; Read the exact source/dataset version detail and compare custodian to the submitted value.; Revise custodian under v2 without overwriting v1; reopen both versions.; Remove or restrict the referenced metadata/source grant and verify honest missing/access status under its policy.
Expected result: Retain custodian unchanged on the correct version, with owner/custodian distinctions and history. Missing or unapproved metadata is explicit; it does not become approved rights or an observation.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR029-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE; licence=SYN-LICENCE-A.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 with licence and all other declared synthetic catalogue metadata.; Read the exact source/dataset version detail and compare licence to the submitted value.; Revise licence under v2 without overwriting v1; reopen both versions.; Remove or restrict the referenced metadata/source grant and verify honest missing/access status under its policy.
Expected result: Retain licence unchanged on the correct version, with owner/custodian distinctions and history. Missing or unapproved metadata is explicit; it does not become approved rights or an observation.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR029-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE; cadence=SYN-PERIODIC-A.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 with cadence and all other declared synthetic catalogue metadata.; Read the exact source/dataset version detail and compare cadence to the submitted value.; Revise cadence under v2 without overwriting v1; reopen both versions.; Remove or restrict the referenced metadata/source grant and verify honest missing/access status under its policy.
Expected result: Retain cadence unchanged on the correct version, with owner/custodian distinctions and history. Missing or unapproved metadata is explicit; it does not become approved rights or an observation.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR029-C05-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE; coverage=SYN-AREA-A, period P0–P1.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 with coverage and all other declared synthetic catalogue metadata.; Read the exact source/dataset version detail and compare coverage to the submitted value.; Revise coverage under v2 without overwriting v1; reopen both versions.; Remove or restrict the referenced metadata/source grant and verify honest missing/access status under its policy.
Expected result: Retain coverage unchanged on the correct version, with owner/custodian distinctions and history. Missing or unapproved metadata is explicit; it does not become approved rights or an observation.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR029-C06-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE; quality=unreviewed synthetic input.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 with quality and all other declared synthetic catalogue metadata.; Read the exact source/dataset version detail and compare quality to the submitted value.; Revise quality under v2 without overwriting v1; reopen both versions.; Remove or restrict the referenced metadata/source grant and verify honest missing/access status under its policy.
Expected result: Retain quality unchanged on the correct version, with owner/custodian distinctions and history. Missing or unapproved metadata is explicit; it does not become approved rights or an observation.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR029-C07-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE; classification=Internal test fixture.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 with classification and all other declared synthetic catalogue metadata.; Read the exact source/dataset version detail and compare classification to the submitted value.; Revise classification under v2 without overwriting v1; reopen both versions.; Remove or restrict the referenced metadata/source grant and verify honest missing/access status under its policy.
Expected result: Retain classification unchanged on the correct version, with owner/custodian distinctions and history. Missing or unapproved metadata is explicit; it does not become approved rights or an observation.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR029-C08-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE; versions=['v1', 'v2'].
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 with versions and all other declared synthetic catalogue metadata.; Read the exact source/dataset version detail and compare versions to the submitted value.; Revise versions under v2 without overwriting v1; reopen both versions.; Remove or restrict the referenced metadata/source grant and verify honest missing/access status under its policy.
Expected result: Retain versions unchanged on the correct version, with owner/custodian distinctions and history. Missing or unapproved metadata is explicit; it does not become approved rights or an observation.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR029-C09-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE; distribution=SYN-FILE-A-v1.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 with distribution and all other declared synthetic catalogue metadata.; Read the exact source/dataset version detail and compare distribution to the submitted value.; Revise distribution under v2 without overwriting v1; reopen both versions.; Remove or restrict the referenced metadata/source grant and verify honest missing/access status under its policy.
Expected result: Retain distribution unchanged on the correct version, with owner/custodian distinctions and history. Missing or unapproved metadata is explicit; it does not become approved rights or an observation.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR029-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR029.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR030-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: SHARED must expose each dataset version's field definitions, types, units and supported integration method. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR030-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR030.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR031-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: SHARED must record each indicator definition's unit, owner, frequency, disaggregation, baseline and target descriptive information, and required sources. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR031-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: Observations require approved contracts. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR031-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR031.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR032-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: SHARED must keep unchanged or versioned staged input, then use the approved defined data structures for accepted records. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR032-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: Do not create a single store of values without defined types and meanings. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR032-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR032.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR033-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: SHARED must use shared assigned work, responses, evidence and review for dataset requests and quality feedback. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR033-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: Show permitted usage relationships without claiming complete view/download telemetry. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR033-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR033.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR034-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: SHARED must retain reviewed links from domain fields to dataset fields that identify the shared field and version, permitted area and period, and actual source availability. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR034-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: A field link must not copy values or approve observations. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR034-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR034.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR035-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: SHARED must require external contributors to use authenticated web, mobile or API workflows. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR035-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: They must not read or write database tables directly. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR036-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: SHARED must enforce the configured workflow for draft, submission, validation, review, return, approval, publication and archive steps. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR036-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: Invalid transitions must fail atomically. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR036-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR036.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR037-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: SHARED must retain source, submitter, organization, time, reporting period, schema version, rights, owner, sensitivity and validation outcomes as unchanged or versioned evidence. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR037-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR037.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR038-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: SHARED must store the supplied source resources, source rows and measured location accuracy with the shared observation. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR038-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: Reject unsupported precision, overflow and excessive text instead of silently changing it. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR038-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR038.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR039-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: SHARED must use configured field types and checks. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR039-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: Missing values, zero and false must remain different. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR039-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: Unknown observation time and GN must not be guessed. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR039-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR039.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR040-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: SHARED must reuse published forms for surveys, trials, training and field feedback. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR040-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SOURCE with explicit versions and accepted parameters: P_ALLOWED_AUDIENCE, P_USE_PURPOSE, P_RIGHTS_EXPIRY, P_ACCEPTED_SOURCE_MAPPING. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SOURCE: Catalogue metadata, exact source versions and allowed uses. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-SOURCE-A@v1 using the declared owner, custodian, licence, cadence, coverage and distribution.; Read that exact version from the catalogue; create v2 without rewriting v1.; Compare stored metadata and explicit rights to the submitted values; unknown attributes stay unknown.
Expected result: When a form value is used in a report field, keep the approved mapping and the link back to the submitted evidence. Compare the exact named value/state/link in FIX-SOURCE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR040-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR040.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: catalogue list; source/dataset version detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR041-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-IMPORT with explicit versions and accepted parameters: P_SUPPORTED_CONTRACT, P_REQUIRED_FIELDS, P_FILE_SIZE_LIMIT, P_INCLUDED_ROW_IDS, P_APPROVAL_VERSION, P_DUPLICATE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-IMPORT: Structured import, mapping, preview, independent approval and retry. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the three declared synthetic rows in each applicable supported format and retain the quarantined original.; Map to SYN-SCHEMA-v1, inspect row validation/preview and independently approve the exact included row list.; Save/retry the batch using SYN-IMPORT-CMD-A; reconcile included/rejected rows and preserve the original.
Expected result: SHARED must process every structured dataset import, including project and deliverable onboarding, through a published CSV, Excel, JSON or restricted XML contract, a quarantined original, row validation and a preview. Compare the exact named value/state/link in FIX-IMPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR041-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR041.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR042-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-IMPORT with explicit versions and accepted parameters: P_SUPPORTED_CONTRACT, P_REQUIRED_FIELDS, P_FILE_SIZE_LIMIT, P_INCLUDED_ROW_IDS, P_APPROVAL_VERSION, P_DUPLICATE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-IMPORT: Structured import, mapping, preview, independent approval and retry. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the three declared synthetic rows in each applicable supported format and retain the quarantined original.; Map to SYN-SCHEMA-v1, inspect row validation/preview and independently approve the exact included row list.; Save/retry the batch using SYN-IMPORT-CMD-A; reconcile included/rejected rows and preserve the original.
Expected result: SHARED must bind independent import approval to the exact list of included rows and target schema. Compare the exact named value/state/link in FIX-IMPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR042-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR042.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR043-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-IMPORT with explicit versions and accepted parameters: P_SUPPORTED_CONTRACT, P_REQUIRED_FIELDS, P_FILE_SIZE_LIMIT, P_INCLUDED_ROW_IDS, P_APPROVAL_VERSION, P_DUPLICATE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-IMPORT: Structured import, mapping, preview, independent approval and retry. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the three declared synthetic rows in each applicable supported format and retain the quarantined original.; Map to SYN-SCHEMA-v1, inspect row validation/preview and independently approve the exact included row list.; Save/retry the batch using SYN-IMPORT-CMD-A; reconcile included/rejected rows and preserve the original.
Expected result: SHARED must retain auditable batches, rows, validation decisions, source evidence and corrective follow-up, protected by their access scope. Compare the exact named value/state/link in FIX-IMPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR043-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR043.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR044-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-IMPORT with explicit versions and accepted parameters: P_SUPPORTED_CONTRACT, P_REQUIRED_FIELDS, P_FILE_SIZE_LIMIT, P_INCLUDED_ROW_IDS, P_APPROVAL_VERSION, P_DUPLICATE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-IMPORT: Structured import, mapping, preview, independent approval and retry. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the three declared synthetic rows in each applicable supported format and retain the quarantined original.; Map to SYN-SCHEMA-v1, inspect row validation/preview and independently approve the exact included row list.; Save/retry the batch using SYN-IMPORT-CMD-A; reconcile included/rejected rows and preserve the original.
Expected result: SHARED must keep the same identifier when an upload or command is retried. Compare the exact named value/state/link in FIX-IMPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR044-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-IMPORT with explicit versions and accepted parameters: P_SUPPORTED_CONTRACT, P_REQUIRED_FIELDS, P_FILE_SIZE_LIMIT, P_INCLUDED_ROW_IDS, P_APPROVAL_VERSION, P_DUPLICATE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-IMPORT: Structured import, mapping, preview, independent approval and retry. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the three declared synthetic rows in each applicable supported format and retain the quarantined original.; Map to SYN-SCHEMA-v1, inspect row validation/preview and independently approve the exact included row list.; Save/retry the batch using SYN-IMPORT-CMD-A; reconcile included/rejected rows and preserve the original.
Expected result: If the response is lost, retain the protected original and check the saved outcome before trying again. Compare the exact named value/state/link in FIX-IMPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR044-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-IMPORT with explicit versions and accepted parameters: P_SUPPORTED_CONTRACT, P_REQUIRED_FIELDS, P_FILE_SIZE_LIMIT, P_INCLUDED_ROW_IDS, P_APPROVAL_VERSION, P_DUPLICATE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-IMPORT: Structured import, mapping, preview, independent approval and retry. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the three declared synthetic rows in each applicable supported format and retain the quarantined original.; Map to SYN-SCHEMA-v1, inspect row validation/preview and independently approve the exact included row list.; Save/retry the batch using SYN-IMPORT-CMD-A; reconcile included/rejected rows and preserve the original.
Expected result: Never change the earlier evidence to make the retry appear successful. Compare the exact named value/state/link in FIX-IMPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR044-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR044.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR045-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-IMPORT with explicit versions and accepted parameters: P_SUPPORTED_CONTRACT, P_REQUIRED_FIELDS, P_FILE_SIZE_LIMIT, P_INCLUDED_ROW_IDS, P_APPROVAL_VERSION, P_DUPLICATE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-IMPORT: Structured import, mapping, preview, independent approval and retry. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the three declared synthetic rows in each applicable supported format and retain the quarantined original.; Map to SYN-SCHEMA-v1, inspect row validation/preview and independently approve the exact included row list.; Save/retry the batch using SYN-IMPORT-CMD-A; reconcile included/rejected rows and preserve the original.
Expected result: SHARED must support CSV, XLSX, JSON arrays of scalar-valued records and restricted XML row documents through one versioned mapping and validation workflow. Compare the exact named value/state/link in FIX-IMPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR045-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-IMPORT with explicit versions and accepted parameters: P_SUPPORTED_CONTRACT, P_REQUIRED_FIELDS, P_FILE_SIZE_LIMIT, P_INCLUDED_ROW_IDS, P_APPROVAL_VERSION, P_DUPLICATE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-IMPORT: Structured import, mapping, preview, independent approval and retry. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the three declared synthetic rows in each applicable supported format and retain the quarantined original.; Map to SYN-SCHEMA-v1, inspect row validation/preview and independently approve the exact included row list.; Save/retry the batch using SYN-IMPORT-CMD-A; reconcile included/rejected rows and preserve the original.
Expected result: Reject unsupported nesting and oversized content. Compare the exact named value/state/link in FIX-IMPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR045-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-IMPORT with explicit versions and accepted parameters: P_SUPPORTED_CONTRACT, P_REQUIRED_FIELDS, P_FILE_SIZE_LIMIT, P_INCLUDED_ROW_IDS, P_APPROVAL_VERSION, P_DUPLICATE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-IMPORT: Structured import, mapping, preview, independent approval and retry. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the three declared synthetic rows in each applicable supported format and retain the quarantined original.; Map to SYN-SCHEMA-v1, inspect row validation/preview and independently approve the exact included row list.; Save/retry the batch using SYN-IMPORT-CMD-A; reconcile included/rejected rows and preserve the original.
Expected result: Never execute spreadsheet formulas, macros, XML DTDs or external entities. Compare the exact named value/state/link in FIX-IMPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR045-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR045.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR046-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-IMPORT with explicit versions and accepted parameters: P_SUPPORTED_CONTRACT, P_REQUIRED_FIELDS, P_FILE_SIZE_LIMIT, P_INCLUDED_ROW_IDS, P_APPROVAL_VERSION, P_DUPLICATE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-IMPORT: Structured import, mapping, preview, independent approval and retry. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the three declared synthetic rows in each applicable supported format and retain the quarantined original.; Map to SYN-SCHEMA-v1, inspect row validation/preview and independently approve the exact included row list.; Save/retry the batch using SYN-IMPORT-CMD-A; reconcile included/rejected rows and preserve the original.
Expected result: SHARED must record original checksum, owner, classification and source purpose. Compare the exact named value/state/link in FIX-IMPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR046-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-IMPORT with explicit versions and accepted parameters: P_SUPPORTED_CONTRACT, P_REQUIRED_FIELDS, P_FILE_SIZE_LIMIT, P_INCLUDED_ROW_IDS, P_APPROVAL_VERSION, P_DUPLICATE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-IMPORT: Structured import, mapping, preview, independent approval and retry. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the three declared synthetic rows in each applicable supported format and retain the quarantined original.; Map to SYN-SCHEMA-v1, inspect row validation/preview and independently approve the exact included row list.; Save/retry the batch using SYN-IMPORT-CMD-A; reconcile included/rejected rows and preserve the original.
Expected result: Reuse matching sources only within compatible scope. Compare the exact named value/state/link in FIX-IMPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR046-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-IMPORT with explicit versions and accepted parameters: P_SUPPORTED_CONTRACT, P_REQUIRED_FIELDS, P_FILE_SIZE_LIMIT, P_INCLUDED_ROW_IDS, P_APPROVAL_VERSION, P_DUPLICATE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-IMPORT: Structured import, mapping, preview, independent approval and retry. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the three declared synthetic rows in each applicable supported format and retain the quarantined original.; Map to SYN-SCHEMA-v1, inspect row validation/preview and independently approve the exact included row list.; Save/retry the batch using SYN-IMPORT-CMD-A; reconcile included/rejected rows and preserve the original.
Expected result: requirements or guidance must not become observations automatically. Compare the exact named value/state/link in FIX-IMPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR046-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR046.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: upload/mapping preview; row validation results; batch receipt/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR047-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-EXTRACTION with explicit versions and accepted parameters: P_PROCESSOR_PERMISSION, P_CLEAN_SCAN_RECEIPT, P_SUPPORTED_DESTINATION, P_CURRENT_DEFINITION_VERSION, P_INDEPENDENT_REVIEWER. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-EXTRACTION: Original document, suggestion provenance and human validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-DOC-A@v1 with its exact synthetic passage and processing permission.; Run only a permitted clean-processing fixture; map SYN-SUG-A to SYN-MAP-v1 and submit it to a separate reviewer.; Compare original passage/locator, uncertainty, suggestion and value-review decisions; missing setup remains blocked.
Expected result: SHARED must require approved provider configuration, processing permission and genuine clean scanning before document processing. Compare the exact named value/state/link in FIX-EXTRACTION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR047-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-EXTRACTION with explicit versions and accepted parameters: P_PROCESSOR_PERMISSION, P_CLEAN_SCAN_RECEIPT, P_SUPPORTED_DESTINATION, P_CURRENT_DEFINITION_VERSION, P_INDEPENDENT_REVIEWER. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-EXTRACTION: Original document, suggestion provenance and human validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-DOC-A@v1 with its exact synthetic passage and processing permission.; Run only a permitted clean-processing fixture; map SYN-SUG-A to SYN-MAP-v1 and submit it to a separate reviewer.; Compare original passage/locator, uncertainty, suggestion and value-review decisions; missing setup remains blocked.
Expected result: Missing setup must be visible. Compare the exact named value/state/link in FIX-EXTRACTION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR047-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-EXTRACTION with explicit versions and accepted parameters: P_PROCESSOR_PERMISSION, P_CLEAN_SCAN_RECEIPT, P_SUPPORTED_DESTINATION, P_CURRENT_DEFINITION_VERSION, P_INDEPENDENT_REVIEWER. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-EXTRACTION: Original document, suggestion provenance and human validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-DOC-A@v1 with its exact synthetic passage and processing permission.; Run only a permitted clean-processing fixture; map SYN-SUG-A to SYN-MAP-v1 and submit it to a separate reviewer.; Compare original passage/locator, uncertainty, suggestion and value-review decisions; missing setup remains blocked.
Expected result: never invent a scan or extraction result. Compare the exact named value/state/link in FIX-EXTRACTION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR048-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-EXTRACTION with explicit versions and accepted parameters: P_PROCESSOR_PERMISSION, P_CLEAN_SCAN_RECEIPT, P_SUPPORTED_DESTINATION, P_CURRENT_DEFINITION_VERSION, P_INDEPENDENT_REVIEWER. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-EXTRACTION: Original document, suggestion provenance and human validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-DOC-A@v1 with its exact synthetic passage and processing permission.; Run only a permitted clean-processing fixture; map SYN-SUG-A to SYN-MAP-v1 and submit it to a separate reviewer.; Compare original passage/locator, uncertainty, suggestion and value-review decisions; missing setup remains blocked.
Expected result: SHARED must retain the original passage, table or page, uncertainty and processing record with each extraction suggestion. Compare the exact named value/state/link in FIX-EXTRACTION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR048-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-EXTRACTION with explicit versions and accepted parameters: P_PROCESSOR_PERMISSION, P_CLEAN_SCAN_RECEIPT, P_SUPPORTED_DESTINATION, P_CURRENT_DEFINITION_VERSION, P_INDEPENDENT_REVIEWER. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-EXTRACTION: Original document, suggestion provenance and human validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-DOC-A@v1 with its exact synthetic passage and processing permission.; Run only a permitted clean-processing fixture; map SYN-SUG-A to SYN-MAP-v1 and submit it to a separate reviewer.; Compare original passage/locator, uncertainty, suggestion and value-review decisions; missing setup remains blocked.
Expected result: Values must use allowed shared data types and destinations. Compare the exact named value/state/link in FIX-EXTRACTION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR048-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR048.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR049-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-EXTRACTION with explicit versions and accepted parameters: P_PROCESSOR_PERMISSION, P_CLEAN_SCAN_RECEIPT, P_SUPPORTED_DESTINATION, P_CURRENT_DEFINITION_VERSION, P_INDEPENDENT_REVIEWER. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-EXTRACTION: Original document, suggestion provenance and human validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-DOC-A@v1 with its exact synthetic passage and processing permission.; Run only a permitted clean-processing fixture; map SYN-SUG-A to SYN-MAP-v1 and submit it to a separate reviewer.; Compare original passage/locator, uncertainty, suggestion and value-review decisions; missing setup remains blocked.
Expected result: SHARED must require permitted users to verify every proposed base domain, subject, attribute and value. Compare the exact named value/state/link in FIX-EXTRACTION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR049-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-EXTRACTION with explicit versions and accepted parameters: P_PROCESSOR_PERMISSION, P_CLEAN_SCAN_RECEIPT, P_SUPPORTED_DESTINATION, P_CURRENT_DEFINITION_VERSION, P_INDEPENDENT_REVIEWER. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-EXTRACTION: Original document, suggestion provenance and human validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-DOC-A@v1 with its exact synthetic passage and processing permission.; Run only a permitted clean-processing fixture; map SYN-SUG-A to SYN-MAP-v1 and submit it to a separate reviewer.; Compare original passage/locator, uncertainty, suggestion and value-review decisions; missing setup remains blocked.
Expected result: Route approved mappings through the relevant shared dataset batches and independent reviews. Compare the exact named value/state/link in FIX-EXTRACTION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR049-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR049.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR050-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-EXTRACTION with explicit versions and accepted parameters: P_PROCESSOR_PERMISSION, P_CLEAN_SCAN_RECEIPT, P_SUPPORTED_DESTINATION, P_CURRENT_DEFINITION_VERSION, P_INDEPENDENT_REVIEWER. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-EXTRACTION: Original document, suggestion provenance and human validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-DOC-A@v1 with its exact synthetic passage and processing permission.; Run only a permitted clean-processing fixture; map SYN-SUG-A to SYN-MAP-v1 and submit it to a separate reviewer.; Compare original passage/locator, uncertainty, suggestion and value-review decisions; missing setup remains blocked.
Expected result: SHARED must record the mapping decision separately from the review of extracted values. Compare the exact named value/state/link in FIX-EXTRACTION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR050-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-EXTRACTION with explicit versions and accepted parameters: P_PROCESSOR_PERMISSION, P_CLEAN_SCAN_RECEIPT, P_SUPPORTED_DESTINATION, P_CURRENT_DEFINITION_VERSION, P_INDEPENDENT_REVIEWER. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-EXTRACTION: Original document, suggestion provenance and human validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-DOC-A@v1 with its exact synthetic passage and processing permission.; Run only a permitted clean-processing fixture; map SYN-SUG-A to SYN-MAP-v1 and submit it to a separate reviewer.; Compare original passage/locator, uncertainty, suggestion and value-review decisions; missing setup remains blocked.
Expected result: Keep rejected suggestions and corrections. Compare the exact named value/state/link in FIX-EXTRACTION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR050-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-EXTRACTION with explicit versions and accepted parameters: P_PROCESSOR_PERMISSION, P_CLEAN_SCAN_RECEIPT, P_SUPPORTED_DESTINATION, P_CURRENT_DEFINITION_VERSION, P_INDEPENDENT_REVIEWER. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-EXTRACTION: Original document, suggestion provenance and human validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-DOC-A@v1 with its exact synthetic passage and processing permission.; Run only a permitted clean-processing fixture; map SYN-SUG-A to SYN-MAP-v1 and submit it to a separate reviewer.; Compare original passage/locator, uncertainty, suggestion and value-review decisions; missing setup remains blocked.
Expected result: Before saving, check permission and the current destination version again. Compare the exact named value/state/link in FIX-EXTRACTION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR050-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR050.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: original preview; suggestion/mapping review; value validation receipt
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR051-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: SHARED must bind each feed's source and dataset version to approved fields, keys, units, location context and origin designation. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR051-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: Disabled feeds cannot acquire or ingest new events. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR051-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: Configuration changes preserve history. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR051-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: invalidate affected approvals. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR051-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR051.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR052-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: SHARED must record source-event, observation-time, applicable device and value-field mappings for provider messages. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR052-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: An independent reviewer approves them. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR052-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: a mapping or governing-field change invalidates approval. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR052-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR052.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR053-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: SHARED must provide adapters for institutional data services and device gateways using approved message contracts. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR053-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: An unsupported source or message format requires an accepted adapter contract before connection. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR053-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR053.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR054-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: SHARED must retain the source message identity, observed and received times, mapping version, staged-pending rows and rejected-row reasons in each intake receipt. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR054-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR054.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR055-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: SHARED must reuse unchanged source events and require an explicit correction for changed content. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR055-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: Keep out-of-order arrival distinct from revision. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR055-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: Retained archive batches must use their documented all-or-none saving and duplicate checks. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR055-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR055.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR056-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-FEED with explicit versions and accepted parameters: P_ENABLED_FEED, P_APPROVED_ADAPTER_CONTRACT, P_EXACT_SOURCE_VERSION, P_FIELD_UNIT_MAPPING, P_GATEWAY_PERMISSION, P_ALL_OR_NONE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-FEED: Approved mapping, replayed messages and source-event identity. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register disabled SYN-FEED-A with source v1 and SYN-FEED-MAP-v1; provide only a local replay contract.; Approve and enable the mapping in the isolated test, replay SYN-MSG-A, then replay its unchanged/changed variants.; Reconcile message identity, observed/received times, origin, pending/rejected rows and duplicate/correction outcomes.
Expected result: SHARED must keep connections inactive until a real endpoint, protected machine identity, rights and mapping review have been supplied. Compare the exact named value/state/link in FIX-FEED under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: feed configuration; intake receipt; source-event history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR057-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: SHARED must retain versions, reasons, source references and permitted history for quality issues and observation corrections. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR057-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR057.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR058-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: SHARED must use the same published checks for numeric values, text, required dates and source identifiers on every entry route. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR058-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: Changing a rule already used by records requires a reviewed new version. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR058-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR058.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR059-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: SHARED must prevent candidate identity suggestions from approving themselves. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR059-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: Link source keys to a permitted registered object only through the reviewed workflow, preserving source-specific scope. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR059-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR059.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR060-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: SHARED must retain both originals and their units, places, dates, methods, review and origin when comparing source-reported values. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR060-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: Do not silently average or overwrite conflicting claims. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR060-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR060.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR061-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: When a reviewer chooses a source, record the purpose and evidence for that choice. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR061-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: Check that units, place, period, field mapping and review are suitable. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR061-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: Recheck the choice after a source changes. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR061-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR061.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR062-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: Provide one worklist for reviewing values, correcting errors and comparing sources. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR062-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: Keep versions of field and related-field rules. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR062-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed provider/data owner, steward and receiving institutional reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLAIMS with explicit versions and accepted parameters: P_COMPARABLE_UNIT_PLACE_PERIOD, P_REVIEW_AUTHORITY, P_APPROVED_PLAUSIBILITY_RULE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLAIMS: Preserved source claims and reviewed correction choices. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the separate 10 ha and 8 ha claims with their exact source, method, place and P0 period.; Open the shared comparison/review worklist, record a permitted reasoned choice and then revise one source.; Both originals remain available; the choice and derived results recheck compatibility/version without silent averaging.
Expected result: Experts must approve scientific plausibility checks, calibration and specialist rules before those checks are used. Compare the exact named value/state/link in FIX-CLAIMS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR062-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR062.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: quality/comparison worklist; claim detail/history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR001-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-ORG-A,SYN-UNIT-A,SYN-STAKEHOLDER-A and SYN-CONTACT-A; separate SYN-ACCOUNT-A.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create each organisation/unit/stakeholder/contact through the permitted administration form with synthetic labels only.; Link SYN-CONTACT-A to the stakeholder without creating or merging SYN-ACCOUNT-A.; Edit/deactivate the contact/unit, reopen its permitted detail and inspect deactivation history.
Expected result: The administered records remain separate from login accounts and preserve authorised change/deactivation history.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR001-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-ORG-A,SYN-UNIT-A,SYN-STAKEHOLDER-A and SYN-CONTACT-A; separate SYN-ACCOUNT-A.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create each organisation/unit/stakeholder/contact through the permitted administration form with synthetic labels only.; Link SYN-CONTACT-A to the stakeholder without creating or merging SYN-ACCOUNT-A.; Edit/deactivate the contact/unit, reopen its permitted detail and inspect deactivation history.
Expected result: The administered records remain separate from login accounts and preserve authorised change/deactivation history.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR001-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-ORG-A,SYN-UNIT-A,SYN-STAKEHOLDER-A and SYN-CONTACT-A; separate SYN-ACCOUNT-A.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create each organisation/unit/stakeholder/contact through the permitted administration form with synthetic labels only.; Link SYN-CONTACT-A to the stakeholder without creating or merging SYN-ACCOUNT-A.; Edit/deactivate the contact/unit, reopen its permitted detail and inspect deactivation history.
Expected result: The administered records remain separate from login accounts and preserve authorised change/deactivation history.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR001-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR001.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR002-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-ACCOUNT-A; SYN-GROUP-A; SYN-ROLE-A; P_PERMISSION_SET; open registration not selected.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Use an authorised synthetic administrator to change account state,group membership,role and permission assignments.; Repeat each change as SYN-USER-DENIED and inspect unchanged assignments.; Attempt open self-registration while disabled and inspect redacted administrative audit.
Expected result: Only authorised changes persist with truthful audit; an unapproved open-registration route does not activate an account.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR002-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-ACCOUNT-A; SYN-GROUP-A; SYN-ROLE-A; P_PERMISSION_SET; open registration not selected.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Use an authorised synthetic administrator to change account state,group membership,role and permission assignments.; Repeat each change as SYN-USER-DENIED and inspect unchanged assignments.; Attempt open self-registration while disabled and inspect redacted administrative audit.
Expected result: Only authorised changes persist with truthful audit; an unapproved open-registration route does not activate an account.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR002-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR002.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR003-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-DELEGATION-A grants only P_PERMISSION_SET during T_START–T_END; SYN-DELEGATE-A.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Assign the scoped delegation and use it within its permitted period.; Attempt the same action before T_START,at/after its policy expiry and in SYN-ORG-B.; Have the delegate attempt a further grant outside its delegable power.
Expected result: Effective dates,scope and delegable powers bound every operation; an over-grant or expired/out-of-scope action fails without new authority.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR003-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-DELEGATION-A grants only P_PERMISSION_SET during T_START–T_END; SYN-DELEGATE-A.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Assign the scoped delegation and use it within its permitted period.; Attempt the same action before T_START,at/after its policy expiry and in SYN-ORG-B.; Have the delegate attempt a further grant outside its delegable power.
Expected result: Effective dates,scope and delegable powers bound every operation; an over-grant or expired/out-of-scope action fails without new authority.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR003-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR003.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR004-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SECURITY with explicit versions and accepted parameters: P_LOCKOUT_ATTEMPTS, P_LOCKOUT_WINDOW, P_LOCKOUT_RECOVERY, P_TOKEN_EXPIRY, P_MFA_ROLE_SET, P_APPROVED_HASH_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-ACCOUNT-A active; ephemeral execution-only valid and invalid secrets.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-ACCOUNT-A through the isolated account administration operation.; Sign in with the valid execution-only secret, then with an invalid secret and a disabled-account variation.; Use the issued session on an authenticated test action and inspect redacted sign-in/audit outcomes.
Expected result: Only the active valid account obtains a usable session. Invalid/disabled attempts do not reveal account secrets or protected data.
Output paths: sign-in; factor challenge; token/session use; redacted authentication audit
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR004-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SECURITY with explicit versions and accepted parameters: P_LOCKOUT_ATTEMPTS, P_LOCKOUT_WINDOW, P_LOCKOUT_RECOVERY, P_TOKEN_EXPIRY, P_MFA_ROLE_SET, P_APPROVED_HASH_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-ACCOUNT-A; P_APPROVED_HASH_POLICY; execution-only secret never retained in this register.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Set and change the execution-only secret using the approved credential operation.; Use an authorised isolated credential-policy diagnostic to verify the stored representation follows P_APPROVED_HASH_POLICY without exporting its bytes.; Verify the old secret no longer signs in and logs contain no secret or reusable credential material.
Expected result: The approved salted adaptive credential policy applies; the original secret is not stored or logged. No custom cryptographic method is introduced.
Output paths: sign-in; factor challenge; token/session use; redacted authentication audit
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR004-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SECURITY with explicit versions and accepted parameters: P_LOCKOUT_ATTEMPTS, P_LOCKOUT_WINDOW, P_LOCKOUT_RECOVERY, P_TOKEN_EXPIRY, P_MFA_ROLE_SET, P_APPROVED_HASH_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-ACCOUNT-A; approved lockout threshold L, window W and recovery policy.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Attempt invalid sign-in L−1 times within W and inspect state.; Attempt the Lth and L+1 invalid sign-in and then a correct secret.; Apply the configured recovery/unlock policy and repeat a valid sign-in.
Expected result: Lockout boundaries and recovery match the accepted policy exactly; a locked account does not obtain a session. L/W are not invented by the test.
Output paths: sign-in; factor challenge; token/session use; redacted authentication audit
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR004-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SECURITY with explicit versions and accepted parameters: P_LOCKOUT_ATTEMPTS, P_LOCKOUT_WINDOW, P_LOCKOUT_RECOVERY, P_TOKEN_EXPIRY, P_MFA_ROLE_SET, P_APPROVED_HASH_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-ACCOUNT-A token with accepted expiry T_EXP.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Obtain an ephemeral token at T0 with declared T_EXP.; Attempt the same protected action immediately before expiry, at expiry and immediately after expiry.; Inspect safe error and audit evidence without recording token bytes.
Expected result: Only the policy-permitted pre-expiry use succeeds. Expired token use is denied consistently; no resource change occurs.
Output paths: sign-in; factor challenge; token/session use; redacted authentication audit
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR004-C05-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SECURITY with explicit versions and accepted parameters: P_LOCKOUT_ATTEMPTS, P_LOCKOUT_WINDOW, P_LOCKOUT_RECOVERY, P_TOKEN_EXPIRY, P_MFA_ROLE_SET, P_APPROVED_HASH_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-SESSION-A active, then revoked; all approved access channels.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Sign in and use SYN-SESSION-A for a permitted action.; Revoke that session through the authorised operation.; Retry protected action and refresh/renewal from each approved channel.
Expected result: Revoked session and renewal attempts cannot continue protected work; the revoke event and permitted internal history remain.
Output paths: sign-in; factor challenge; token/session use; redacted authentication audit
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR004-C06-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SECURITY with explicit versions and accepted parameters: P_LOCKOUT_ATTEMPTS, P_LOCKOUT_WINDOW, P_LOCKOUT_RECOVERY, P_TOKEN_EXPIRY, P_MFA_ROLE_SET, P_APPROVED_HASH_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-ADMIN-A in the administrator role from P_MFA_ROLE_SET.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Complete the password stage for SYN-ADMIN-A.; Attempt a privileged action without the required second factor, then with invalid/expired/replayed factor evidence.; Complete a valid factor through the approved test provider and repeat the action.
Expected result: Administrator privileged access requires the accepted factor policy; omission, invalidity, expiry and replay do not grant access.
Output paths: sign-in; factor challenge; token/session use; redacted authentication audit
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR004-C07-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SECURITY with explicit versions and accepted parameters: P_LOCKOUT_ATTEMPTS, P_LOCKOUT_WINDOW, P_LOCKOUT_RECOVERY, P_TOKEN_EXPIRY, P_MFA_ROLE_SET, P_APPROVED_HASH_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-ACCESS-REVIEWER-A in the privileged access-review role.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Complete sign-in for SYN-ACCESS-REVIEWER-A without its second factor.; Attempt a privileged access-review decision.; Complete the required approved factor and repeat with the same permitted scope.
Expected result: The privileged access-review role cannot bypass required multi-factor verification or resource scope.
Output paths: sign-in; factor challenge; token/session use; redacted authentication audit
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR004-C08-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SECURITY with explicit versions and accepted parameters: P_LOCKOUT_ATTEMPTS, P_LOCKOUT_WINDOW, P_LOCKOUT_RECOVERY, P_TOKEN_EXPIRY, P_MFA_ROLE_SET, P_APPROVED_HASH_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-POLICY-ROLE-A included/excluded under the accepted P_MFA_ROLE_SET.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Bind the additional test role to the selected policy version.; Attempt sign-in and a role action before required factor verification.; Change only the role policy version through authorised review and repeat the boundary check.
Expected result: Any additional role identified by the accepted security policy receives the required factor challenge; the test does not choose real roles or grant authority.
Output paths: sign-in; factor challenge; token/session use; redacted authentication audit
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR005-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: Validated SYN-ACCOUNT-A session; request body claims SYN-ACCOUNT-B or SYN-ORG-B.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Authenticate the isolated test client as SYN-ACCOUNT-A.; Submit an otherwise valid action with another account/scope identifier in its editable request body.; Inspect the actual actor,audit and permission result.
Expected result: The validated server identity remains the actor; an editable request identity/scope never proves permission or impersonates another account.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR005-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: Validated SYN-ACCOUNT-A session; request body claims SYN-ACCOUNT-B or SYN-ORG-B.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Authenticate the isolated test client as SYN-ACCOUNT-A.; Submit an otherwise valid action with another account/scope identifier in its editable request body.; Inspect the actual actor,audit and permission result.
Expected result: The validated server identity remains the actor; an editable request identity/scope never proves permission or impersonates another account.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR006-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-INVITATION-A for intended SYN-ACCOUNT-A; expiry T_EXP; execution-only invitation secret.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Issue the bounded invitation for SYN-ACCOUNT-A through the approved delivery fixture.; Try another account,an expired use and a second use after valid activation.; Simulate unavailable delivery/recovery setup and inspect honest states and redacted diagnostics.
Expected result: Only the intended account can activate once within the accepted validity rule; failed delivery/recovery is not shown as success and secrets are not logged.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR006-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-INVITATION-A for intended SYN-ACCOUNT-A; expiry T_EXP; execution-only invitation secret.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Issue the bounded invitation for SYN-ACCOUNT-A through the approved delivery fixture.; Try another account,an expired use and a second use after valid activation.; Simulate unavailable delivery/recovery setup and inspect honest states and redacted diagnostics.
Expected result: Only the intended account can activate once within the accepted validity rule; failed delivery/recovery is not shown as success and secrets are not logged.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR006-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-INVITATION-A for intended SYN-ACCOUNT-A; expiry T_EXP; execution-only invitation secret.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Issue the bounded invitation for SYN-ACCOUNT-A through the approved delivery fixture.; Try another account,an expired use and a second use after valid activation.; Simulate unavailable delivery/recovery setup and inspect honest states and redacted diagnostics.
Expected result: Only the intended account can activate once within the accepted validity rule; failed delivery/recovery is not shown as success and secrets are not logged.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR007-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: Acting SYN-ACCOUNT-A; selected SYN-STAKEHOLDER-A context; denied SYN-STAKEHOLDER-B.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Select the permitted stakeholder context as the authorised administrator.; Perform a scoped action and inspect its actual acting account and selected context separately.; Request an ungranted stakeholder context through both UI and direct contract input.
Expected result: Context selection does not replace the acting identity or grant an unpermitted stakeholder scope.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR007-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: Acting SYN-ACCOUNT-A; selected SYN-STAKEHOLDER-A context; denied SYN-STAKEHOLDER-B.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Select the permitted stakeholder context as the authorised administrator.; Perform a scoped action and inspect its actual acting account and selected context separately.; Request an ungranted stakeholder context through both UI and direct contract input.
Expected result: Context selection does not replace the acting identity or grant an unpermitted stakeholder scope.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR007-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR007.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR008-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-OBJECT-A linked to SYN-ORG-A,domainA,areaA,projectA,evidenceA and contributionA.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the shared identities once and link the named organisation/domain/geography/project/evidence/contribution records.; Open the same object through each permitted context.; Attempt a duplicate core identity or differently scoped link.
Expected result: Permitted views resolve the same shared identities and workflow provenance without copying a separate core object or leaking scope.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR008-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR008.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR009-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=action; output=all six output paths.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only action; keep all other conditions unchanged.; Repeat all six output paths and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated action mismatch consistently on all six output paths. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=organization; output=all six output paths.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only organization; keep all other conditions unchanged.; Repeat all six output paths and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated organization mismatch consistently on all six output paths. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=stakeholder; output=all six output paths.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only stakeholder; keep all other conditions unchanged.; Repeat all six output paths and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated stakeholder mismatch consistently on all six output paths. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=domain; output=all six output paths.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only domain; keep all other conditions unchanged.; Repeat all six output paths and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated domain mismatch consistently on all six output paths. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C05-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=project; output=all six output paths.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only project; keep all other conditions unchanged.; Repeat all six output paths and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated project mismatch consistently on all six output paths. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C06-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=geography; output=all six output paths.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only geography; keep all other conditions unchanged.; Repeat all six output paths and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated geography mismatch consistently on all six output paths. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C07-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=record; output=all six output paths.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only record; keep all other conditions unchanged.; Repeat all six output paths and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated record mismatch consistently on all six output paths. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C08-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=classification; output=all six output paths.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only classification; keep all other conditions unchanged.; Repeat all six output paths and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated classification mismatch consistently on all six output paths. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C09-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=workflow state; output=all six output paths.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only workflow state; keep all other conditions unchanged.; Repeat all six output paths and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated workflow state mismatch consistently on all six output paths. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C10-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=all nine dimensions; output=lists.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only all nine dimensions; keep all other conditions unchanged.; Repeat lists and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated all nine dimensions mismatch consistently on lists. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C11-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=all nine dimensions; output=counts.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only all nine dimensions; keep all other conditions unchanged.; Repeat counts and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated all nine dimensions mismatch consistently on counts. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C12-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=all nine dimensions; output=maps.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only all nine dimensions; keep all other conditions unchanged.; Repeat maps and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated all nine dimensions mismatch consistently on maps. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C13-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=all nine dimensions; output=files.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only all nine dimensions; keep all other conditions unchanged.; Repeat files and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated all nine dimensions mismatch consistently on files. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-C14-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SCOPE; SYN-REC-A allowed; SYN-REC-B sibling denied; focused dimension=all nine dimensions; output=exports.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the allowed and denied sibling records and grant all required dimensions to SYN-USER-PREP.; Read the allowed baseline across the applicable output paths.; Remove or mismatch only all nine dimensions; keep all other conditions unchanged.; Repeat exports and confirm SYN-REC-B metadata/content never leaks; restore only the changed grant and repeat the allowed case.
Expected result: Deny the isolated all nine dimensions mismatch consistently on exports. Only the genuinely permitted rows and aggregates remain; no object existence, location, file or export leakage.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR009-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR009.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR010-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-DATASET-A owned by SYN-ORG-A; audienceA selected; recipientB cannot re-share.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Have the appointed synthetic sharing-manager role select owner-only and permitted selected-stakeholder audiences.; Apply a dataset-specific override within the parent rule and record its reason.; Attempt recipient re-sharing,self-delegation and an override outside the manager grant.
Expected result: Audience changes obey the shared/dataset rules and audit; recipients cannot acquire re-sharing or self-delegation powers.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR010-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-DATASET-A owned by SYN-ORG-A; audienceA selected; recipientB cannot re-share.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Have the appointed synthetic sharing-manager role select owner-only and permitted selected-stakeholder audiences.; Apply a dataset-specific override within the parent rule and record its reason.; Attempt recipient re-sharing,self-delegation and an override outside the manager grant.
Expected result: Audience changes obey the shared/dataset rules and audit; recipients cannot acquire re-sharing or self-delegation powers.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR010-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-DATASET-A owned by SYN-ORG-A; audienceA selected; recipientB cannot re-share.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Have the appointed synthetic sharing-manager role select owner-only and permitted selected-stakeholder audiences.; Apply a dataset-specific override within the parent rule and record its reason.; Attempt recipient re-sharing,self-delegation and an override outside the manager grant.
Expected result: Audience changes obey the shared/dataset rules and audit; recipients cannot acquire re-sharing or self-delegation powers.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR010-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR010.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR011-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-PARTICIPANT-A added to a permitted stakeholder branch; no account/grant/ownership event.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Read the retained branch configuration as an editable review baseline.; Add SYN-PARTICIPANT-A through the shared identity workflow.; Inspect legal-owner,login-account and access assignments before and after the change.
Expected result: The participant is represented once; adding it does not create legal ownership,a login or access automatically.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR011-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-PARTICIPANT-A added to a permitted stakeholder branch; no account/grant/ownership event.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Read the retained branch configuration as an editable review baseline.; Add SYN-PARTICIPANT-A through the shared identity workflow.; Inspect legal-owner,login-account and access assignments before and after the change.
Expected result: The participant is represented once; adding it does not create legal ownership,a login or access automatically.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR011-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-PARTICIPANT-A added to a permitted stakeholder branch; no account/grant/ownership event.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Read the retained branch configuration as an editable review baseline.; Add SYN-PARTICIPANT-A through the shared identity workflow.; Inspect legal-owner,login-account and access assignments before and after the change.
Expected result: The participant is represented once; adding it does not create legal ownership,a login or access automatically.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR011-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-PARTICIPANT-A added to a permitted stakeholder branch; no account/grant/ownership event.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Read the retained branch configuration as an editable review baseline.; Add SYN-PARTICIPANT-A through the shared identity workflow.; Inspect legal-owner,login-account and access assignments before and after the change.
Expected result: The participant is represented once; adding it does not create legal ownership,a login or access automatically.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR011-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR011.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR012-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-DOMAIN-FOREST owned by SYN-ORG-A; SYN-DOMAIN-WILDLIFE owned by SYN-ORG-B; shared subject link.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the two separate owned domain configurations and their permitted subjects/attributes.; Propose a shared-subject relationship and route it to the required independent review.; Attempt to edit the other owner domain or merge ownership through a common label.
Expected result: Ownership stays separate; only permitted configuration and reviewed relationships apply. A shared subject does not transfer ownership.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR012-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-DOMAIN-FOREST owned by SYN-ORG-A; SYN-DOMAIN-WILDLIFE owned by SYN-ORG-B; shared subject link.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the two separate owned domain configurations and their permitted subjects/attributes.; Propose a shared-subject relationship and route it to the required independent review.; Attempt to edit the other owner domain or merge ownership through a common label.
Expected result: Ownership stays separate; only permitted configuration and reviewed relationships apply. A shared subject does not transfer ownership.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR012-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-DOMAIN-FOREST owned by SYN-ORG-A; SYN-DOMAIN-WILDLIFE owned by SYN-ORG-B; shared subject link.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the two separate owned domain configurations and their permitted subjects/attributes.; Propose a shared-subject relationship and route it to the required independent review.; Attempt to edit the other owner domain or merge ownership through a common label.
Expected result: Ownership stays separate; only permitted configuration and reviewed relationships apply. A shared subject does not transfer ownership.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR012-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR012.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR013-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-DASHBOARD-DEF-A@v1; SYN-PRODUCT-PROPOSAL-A inactive; audienceA and saved preferenceA.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create a dashboard definition with its audience and save an allowed user preference.; Register the proposed product purpose,inputs,coverage and required approval/acceptance references.; Attempt to activate the proposal without the required accepted scope/review evidence.
Expected result: Definitions/preferences remain configurable and scoped; a registered proposal stays inactive until the required authority accepts it.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR013-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-DASHBOARD-DEF-A@v1; SYN-PRODUCT-PROPOSAL-A inactive; audienceA and saved preferenceA.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create a dashboard definition with its audience and save an allowed user preference.; Register the proposed product purpose,inputs,coverage and required approval/acceptance references.; Attempt to activate the proposal without the required accepted scope/review evidence.
Expected result: Definitions/preferences remain configurable and scoped; a registered proposal stays inactive until the required authority accepts it.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR013-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SCOPE with explicit versions and accepted parameters: P_ACTION, P_CLASSIFICATION, P_WORKFLOW_STATE, P_STAKEHOLDER, P_AUDIENCE, P_CURRENT_POLICY_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: SYN-DASHBOARD-DEF-A@v1; SYN-PRODUCT-PROPOSAL-A inactive; audienceA and saved preferenceA.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create a dashboard definition with its audience and save an allowed user preference.; Register the proposed product purpose,inputs,coverage and required approval/acceptance references.; Attempt to activate the proposal without the required accepted scope/review evidence.
Expected result: Definitions/preferences remain configurable and scoped; a registered proposal stays inactive until the required authority accepts it.
Output paths: administration/context form; permitted resource detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR013-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR013.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: administration/context form; permitted resource detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR014-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: SHARED must allow appointed stewards to maintain reviewed domain packs containing schema definitions, vocabularies, units and project or deliverable templates. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR014-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR014.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR015-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: SHARED must limit configuration to reviewed field types, components, validation, vocabulary, geography and evidence definitions. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR015-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: Reject scripts, executable expressions and unknown properties. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR015-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR015.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR016-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: SHARED must keep the exact field definitions and form version used to validate each submitted section. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR016-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: Later template edits must not rewrite that submission. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR016-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR016.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR017-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: SHARED must allow new domains, subjects and attributes that use published supported storage profiles to be configured without deployment. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR017-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR017.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR018-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: SHARED must support hierarchy, translations, effective dates, ordering, aliases and retirement in reference lists. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR018-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: Used identities and meanings must remain stable. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR018-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR018.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR019-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: SHARED must link a controlled record to its primary domain and secondary classifications without copying its core record. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR019-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR019.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR020-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: SHARED must store the initial domain names, field descriptions and allowed choices as editable settings. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR020-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: They must not be fixed in screen code or supplied as sample business records. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR020-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR020.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR021-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: SHARED must reuse existing meanings, fields and units where they are truly the same. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR021-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: Before merging definitions or publishing a change, an authorized reviewer must check possible duplicates and affected records. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR021-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU and proposed institutional access/domain owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DEFINITION with explicit versions and accepted parameters: P_FIELD_TYPE, P_REQUIRED_FIELDS, P_ALLOWED_VOCABULARY, P_LOWER_BOUND_L, P_UPPER_BOUND_U, P_BOUND_INCLUSIVITY, P_MISSING_REASON_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DEFINITION: Typed definitions, source mappings and value meanings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: Similar labels do not prove equal meaning. Compare the exact named value/state/link in FIX-DEFINITION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR021-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR021.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: definition/mapping form; validation result; versioned definition detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR022-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: SHARED must allow appointed stewards to configure independent geography schemes and levels rather than force all places into one hierarchy. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR022-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR022.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR023-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; place SYN-AREA-A; stable code SYN-PLACE-A; stable codes supplied under the accepted geography version. Geometry values are fixture-only, not programme boundaries.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-AREA-A using the approved isolated geography schema and the focused stable codes values.; Read place detail and the applicable map/reference view; compare the exact stored stable codes.; Create a new place revision and retain earlier references.; Supply missing or unsupported stable codes according to the published required/allowed rules and inspect the correction.
Expected result: The focused stable codes value/form and its provenance remain correct and versioned. Unsupported or required-missing input is rejected; unknown accuracy/place/time is never guessed.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR023-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; place SYN-AREA-A; stable code SYN-PLACE-A; names supplied under the accepted geography version. Geometry values are fixture-only, not programme boundaries.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-AREA-A using the approved isolated geography schema and the focused names values.; Read place detail and the applicable map/reference view; compare the exact stored names.; Create a new place revision and retain earlier references.; Supply missing or unsupported names according to the published required/allowed rules and inspect the correction.
Expected result: The focused names value/form and its provenance remain correct and versioned. Unsupported or required-missing input is rejected; unknown accuracy/place/time is never guessed.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR023-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; place SYN-AREA-A; stable code SYN-PLACE-A; aliases supplied under the accepted geography version. Geometry values are fixture-only, not programme boundaries.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-AREA-A using the approved isolated geography schema and the focused aliases values.; Read place detail and the applicable map/reference view; compare the exact stored aliases.; Create a new place revision and retain earlier references.; Supply missing or unsupported aliases according to the published required/allowed rules and inspect the correction.
Expected result: The focused aliases value/form and its provenance remain correct and versioned. Unsupported or required-missing input is rejected; unknown accuracy/place/time is never guessed.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR023-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; place SYN-AREA-A; stable code SYN-PLACE-A; translations supplied under the accepted geography version. Geometry values are fixture-only, not programme boundaries.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-AREA-A using the approved isolated geography schema and the focused translations values.; Read place detail and the applicable map/reference view; compare the exact stored translations.; Create a new place revision and retain earlier references.; Supply missing or unsupported translations according to the published required/allowed rules and inspect the correction.
Expected result: The focused translations value/form and its provenance remain correct and versioned. Unsupported or required-missing input is rejected; unknown accuracy/place/time is never guessed.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR023-C05-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; place SYN-AREA-A; stable code SYN-PLACE-A; geometry supplied under the accepted geography version. Geometry values are fixture-only, not programme boundaries.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-AREA-A using the approved isolated geography schema and the focused geometry values.; Read place detail and the applicable map/reference view; compare the exact stored geometry.; Create a new place revision and retain earlier references.; Supply missing or unsupported geometry according to the published required/allowed rules and inspect the correction.
Expected result: The focused geometry value/form and its provenance remain correct and versioned. Unsupported or required-missing input is rejected; unknown accuracy/place/time is never guessed.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR023-C06-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; place SYN-AREA-A; stable code SYN-PLACE-A; source supplied under the accepted geography version. Geometry values are fixture-only, not programme boundaries.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-AREA-A using the approved isolated geography schema and the focused source values.; Read place detail and the applicable map/reference view; compare the exact stored source.; Create a new place revision and retain earlier references.; Supply missing or unsupported source according to the published required/allowed rules and inspect the correction.
Expected result: The focused source value/form and its provenance remain correct and versioned. Unsupported or required-missing input is rejected; unknown accuracy/place/time is never guessed.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR023-C07-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; place SYN-AREA-A; stable code SYN-PLACE-A; accuracy supplied under the accepted geography version. Geometry values are fixture-only, not programme boundaries.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-AREA-A using the approved isolated geography schema and the focused accuracy values.; Read place detail and the applicable map/reference view; compare the exact stored accuracy.; Create a new place revision and retain earlier references.; Supply missing or unsupported accuracy according to the published required/allowed rules and inspect the correction.
Expected result: The focused accuracy value/form and its provenance remain correct and versioned. Unsupported or required-missing input is rejected; unknown accuracy/place/time is never guessed.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR023-C08-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; place SYN-AREA-A; stable code SYN-PLACE-A; dates supplied under the accepted geography version. Geometry values are fixture-only, not programme boundaries.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-AREA-A using the approved isolated geography schema and the focused dates values.; Read place detail and the applicable map/reference view; compare the exact stored dates.; Create a new place revision and retain earlier references.; Supply missing or unsupported dates according to the published required/allowed rules and inspect the correction.
Expected result: The focused dates value/form and its provenance remain correct and versioned. Unsupported or required-missing input is rejected; unknown accuracy/place/time is never guessed.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR023-C09-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; place SYN-AREA-A; stable code SYN-PLACE-A; version supplied under the accepted geography version. Geometry values are fixture-only, not programme boundaries.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-AREA-A using the approved isolated geography schema and the focused version values.; Read place detail and the applicable map/reference view; compare the exact stored version.; Create a new place revision and retain earlier references.; Supply missing or unsupported version according to the published required/allowed rules and inspect the correction.
Expected result: The focused version value/form and its provenance remain correct and versioned. Unsupported or required-missing input is rejected; unknown accuracy/place/time is never guessed.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR023-C10-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; place SYN-AREA-A; stable code SYN-PLACE-A; status supplied under the accepted geography version. Geometry values are fixture-only, not programme boundaries.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-AREA-A using the approved isolated geography schema and the focused status values.; Read place detail and the applicable map/reference view; compare the exact stored status.; Create a new place revision and retain earlier references.; Supply missing or unsupported status according to the published required/allowed rules and inspect the correction.
Expected result: The focused status value/form and its provenance remain correct and versioned. Unsupported or required-missing input is rejected; unknown accuracy/place/time is never guessed.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR023-C11-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; place SYN-AREA-A; stable code SYN-PLACE-A; point/line/polygon forms supplied under the accepted geography version. Geometry values are fixture-only, not programme boundaries.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-AREA-A using the approved isolated geography schema and the focused point/line/polygon forms values.; Read place detail and the applicable map/reference view; compare the exact stored point/line/polygon forms.; Create a new place revision and retain earlier references.; Supply missing or unsupported point/line/polygon forms according to the published required/allowed rules and inspect the correction.
Expected result: The focused point/line/polygon forms value/form and its provenance remain correct and versioned. Unsupported or required-missing input is rejected; unknown accuracy/place/time is never guessed.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR023-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR023.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR024-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: SHARED must support reviewed hierarchy, containment, overlap and many-to-many links between schemes. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR024-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR024.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR025-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: SHARED must preserve historical references. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR025-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: prevent deletion of used meanings when a place is replaced, split, merged or retired. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR025-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR025.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR026-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: unrecognised or missing CRS; never silently transform it. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused coordinate system variation: unrecognised or missing CRS; never silently transform it.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared coordinate system rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR026-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: point outside the accepted fixture extent. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused bounds variation: point outside the accepted fixture extent.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared bounds rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR026-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: Point submitted to a type allowing only Polygon. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused type variation: Point submitted to a type allowing only Polygon.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared type rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR026-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: malformed coordinates or an invalid ring. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused validity variation: malformed coordinates or an invalid ring.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared validity rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR026-C05-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: the self-intersecting polygon and configured topology violation. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused topology variation: the self-intersecting polygon and configured topology violation.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared topology rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR026-C06-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: V_MAX+1 vertices versus V_MAX, using the accepted limit. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused complexity variation: V_MAX+1 vertices versus V_MAX, using the accepted limit.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared complexity rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR026-C07-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: Q_MAX+1 requested objects/extent versus Q_MAX. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused query limit variation: Q_MAX+1 requested objects/extent versus Q_MAX.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared query limit rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR026-C08-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: unsupported geometry/property/CRS contract. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused unsupported input variation: unsupported geometry/property/CRS contract.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared unsupported input rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR026-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR026.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR027-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: SHARED must enforce the configured Draft, Review, Active and Retired lifecycle for boundaries. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR027-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: High-impact changes need impact preview and independent approval. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR027-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-structure-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR027.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR028-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: SHARED must search GN areas through the shared paged geography reader. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR028-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Keep timeout, missing and denied responses distinct from a valid empty list. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR063-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: SHARED must retain each spatial layer version's source type, geometry or raster descriptive information, coordinate system, scale or resolution, coverage, owner and classification. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR063-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR063.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR064-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: SHARED must make approved map styles, legends, layer groups and saved map workspaces refer to the shared permitted layers. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR064-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: Recheck withdrawn source access. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR064-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR064.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR065-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: SHARED must connect layers to domains, datasets, documents, projects, interventions and geographies without another GIS registry. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR065-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR065.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR066-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: SHARED must enforce device, volume and location-disclosure limits in web and mobile maps. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR066-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: Sensitive exact locations must be hidden or generalized according to approved rules. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR066-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR066.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR067-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: SHARED must exclude positively identified test and demonstration features from operational maps while preserving their history. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR067-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: Unknown origin must not be relabelled real. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR067-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR067.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR068-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: SHARED must use the shared grouped menu, context and progressive layer loading. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR068-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: Cancel old requests. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR068-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: distinguish missing, denied, failed and valid empty results. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR068-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR068.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR069-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: SHARED must support the specified approximate buffer, loaded-feature proximity, selected-polygon overlap and area tools with method, units, inputs and limits. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR069-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR069.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR070-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: SHARED must use actual points. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR070-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: retain scale, denominators and non-estimable states for clustering, record-density grids and exploratory hotspot counts. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR070-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: Do not invent point centres or risk classes. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR070-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR070.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR071-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: SHARED must check coordinate system, grid alignment, units, class meaning and missing cells before supported raster preview, swipe, native-cell summary or change analysis. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR071-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR071.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR072-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: SHARED must keep source versions, context, parameters, fingerprints, limits and outputs. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR072-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: Bound background work, support cancellation. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR072-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: invalidate results after source change. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR072-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR072.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR073-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: SHARED must use the shared source and version workflow for exact lawful originals and supported normalized points or native raster cells. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR073-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: Preserve coordinates, source dates and missing cells. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR073-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR073.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR074-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: SHARED must keep a pending spatial layer unpublished during ingestion. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR074-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: Apply archive, geometry, extent and supported transformation controls. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR074-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-SPATIAL with explicit versions and accepted parameters: P_CRS_RESOLUTION_EXTENT, P_CLASS_MEANING, P_NODATA, P_CELL_ALIGNMENT, P_METHOD_UNITS, P_VOLUME_LIMIT, P_DISCLOSURE_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-SPATIAL: Layer lineage, bounded vector/raster analysis and missing cells. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register SYN-LAYER-A@v1 and the point/polygon or 2×2 native-cell fixture with declared units/CRS/nodata.; Run only the supported bounded analysis for the clause; retain inputs, method, parameters and result.; Reconcile valid cells/features and missing values; change source/context and check stale-result or cancelled-work handling.
Expected result: General conversion, national tiling or every GIS file type must not be claimed. Compare the exact named value/state/link in FIX-SPATIAL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR074-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR074.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: layer/map workspace; analysis result/detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR075-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLIMATE with explicit versions and accepted parameters: P_PRODUCT_VARIABLE_UNIT, P_ACCEPTED_ALLOCATION_METHOD, P_SOURCE_REFRESH_POLICY, P_WARNING_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLIMATE: Observed climate series, forecast validity and no invented warnings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load the declared observed series, missing P1 observation, issue/validity forecast and dated plot-crop record.; Select source/period/location, compare only compatible dated observations and advance beyond forecast validity.; Unknown rainfall/location stays unknown; stale forecasts and failed refresh are visible; no official warning is invented.
Expected result: SHARED must retain source product, variable, location, unit, observation period, receipt time, issue time and forecast validity where supplied. Compare the exact named value/state/link in FIX-CLIMATE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR075-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR075.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR076-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLIMATE with explicit versions and accepted parameters: P_PRODUCT_VARIABLE_UNIT, P_ACCEPTED_ALLOCATION_METHOD, P_SOURCE_REFRESH_POLICY, P_WARNING_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLIMATE: Observed climate series, forecast validity and no invented warnings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load the declared observed series, missing P1 observation, issue/validity forecast and dated plot-crop record.; Select source/period/location, compare only compatible dated observations and advance beyond forecast validity.; Unknown rainfall/location stays unknown; stale forecasts and failed refresh are visible; no official warning is invented.
Expected result: SHARED must show overdue or failed source acquisition and expired retained forecasts in source-refresh views. Compare the exact named value/state/link in FIX-CLIMATE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR076-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLIMATE with explicit versions and accepted parameters: P_PRODUCT_VARIABLE_UNIT, P_ACCEPTED_ALLOCATION_METHOD, P_SOURCE_REFRESH_POLICY, P_WARNING_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLIMATE: Observed climate series, forecast validity and no invented warnings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load the declared observed series, missing P1 observation, issue/validity forecast and dated plot-crop record.; Select source/period/location, compare only compatible dated observations and advance beyond forecast validity.; Unknown rainfall/location stays unknown; stale forecasts and failed refresh are visible; no official warning is invented.
Expected result: Unknown source or period must remain unknown. Compare the exact named value/state/link in FIX-CLIMATE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR076-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR076.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR077-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLIMATE with explicit versions and accepted parameters: P_PRODUCT_VARIABLE_UNIT, P_ACCEPTED_ALLOCATION_METHOD, P_SOURCE_REFRESH_POLICY, P_WARNING_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLIMATE: Observed climate series, forecast validity and no invented warnings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load the declared observed series, missing P1 observation, issue/validity forecast and dated plot-crop record.; Select source/period/location, compare only compatible dated observations and advance beyond forecast validity.; Unknown rainfall/location stays unknown; stale forecasts and failed refresh are visible; no official warning is invented.
Expected result: SHARED must retain the original grid location, period, units, references and origin of retained rainfall source series. Compare the exact named value/state/link in FIX-CLIMATE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR077-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLIMATE with explicit versions and accepted parameters: P_PRODUCT_VARIABLE_UNIT, P_ACCEPTED_ALLOCATION_METHOD, P_SOURCE_REFRESH_POLICY, P_WARNING_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLIMATE: Observed climate series, forecast validity and no invented warnings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load the declared observed series, missing P1 observation, issue/validity forecast and dated plot-crop record.; Select source/period/location, compare only compatible dated observations and advance beyond forecast validity.; Unknown rainfall/location stays unknown; stale forecasts and failed refresh are visible; no official warning is invented.
Expected result: Do not invent a GN assignment or new station. Compare the exact named value/state/link in FIX-CLIMATE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR077-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR077.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR078-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLIMATE with explicit versions and accepted parameters: P_PRODUCT_VARIABLE_UNIT, P_ACCEPTED_ALLOCATION_METHOD, P_SOURCE_REFRESH_POLICY, P_WARNING_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLIMATE: Observed climate series, forecast validity and no invented warnings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load the declared observed series, missing P1 observation, issue/validity forecast and dated plot-crop record.; Select source/period/location, compare only compatible dated observations and advance beyond forecast validity.; Unknown rainfall/location stays unknown; stale forecasts and failed refresh are visible; no official warning is invented.
Expected result: SHARED must require suitable dated records or an approved allocation method for a complete GN rainfall and cultivation comparison. Compare the exact named value/state/link in FIX-CLIMATE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR078-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLIMATE with explicit versions and accepted parameters: P_PRODUCT_VARIABLE_UNIT, P_ACCEPTED_ALLOCATION_METHOD, P_SOURCE_REFRESH_POLICY, P_WARNING_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLIMATE: Observed climate series, forecast validity and no invented warnings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load the declared observed series, missing P1 observation, issue/validity forecast and dated plot-crop record.; Select source/period/location, compare only compatible dated observations and advance beyond forecast validity.; Unknown rainfall/location stays unknown; stale forecasts and failed refresh are visible; no official warning is invented.
Expected result: An undated classification or district statistic cannot supply five annual GN totals. Compare the exact named value/state/link in FIX-CLIMATE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR078-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR078.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR079-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLIMATE with explicit versions and accepted parameters: P_PRODUCT_VARIABLE_UNIT, P_ACCEPTED_ALLOCATION_METHOD, P_SOURCE_REFRESH_POLICY, P_WARNING_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLIMATE: Observed climate series, forecast validity and no invented warnings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load the declared observed series, missing P1 observation, issue/validity forecast and dated plot-crop record.; Select source/period/location, compare only compatible dated observations and advance beyond forecast validity.; Unknown rainfall/location stays unknown; stale forecasts and failed refresh are visible; no official warning is invented.
Expected result: SHARED must require the relevant accepted method, inputs and authority before presenting operational hazard, drought, adaptation or warning outputs. Compare the exact named value/state/link in FIX-CLIMATE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR079-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLIMATE with explicit versions and accepted parameters: P_PRODUCT_VARIABLE_UNIT, P_ACCEPTED_ALLOCATION_METHOD, P_SOURCE_REFRESH_POLICY, P_WARNING_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLIMATE: Observed climate series, forecast validity and no invented warnings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load the declared observed series, missing P1 observation, issue/validity forecast and dated plot-crop record.; Select source/period/location, compare only compatible dated observations and advance beyond forecast validity.; Unknown rainfall/location stays unknown; stale forecasts and failed refresh are visible; no official warning is invented.
Expected result: Recorded context must not become an official warning automatically. Compare the exact named value/state/link in FIX-CLIMATE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR079-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#map-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR079.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR080-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLIMATE with explicit versions and accepted parameters: P_PRODUCT_VARIABLE_UNIT, P_ACCEPTED_ALLOCATION_METHOD, P_SOURCE_REFRESH_POLICY, P_WARNING_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLIMATE: Observed climate series, forecast validity and no invented warnings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load the declared observed series, missing P1 observation, issue/validity forecast and dated plot-crop record.; Select source/period/location, compare only compatible dated observations and advance beyond forecast validity.; Unknown rainfall/location stays unknown; stale forecasts and failed refresh are visible; no official warning is invented.
Expected result: SHARED must reuse society or farmer-group profiles, members, farm plots and plot-crop records with their owner, source, area and permitted review states. Compare the exact named value/state/link in FIX-CLIMATE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR080-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR080.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR081-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CLIMATE with explicit versions and accepted parameters: P_PRODUCT_VARIABLE_UNIT, P_ACCEPTED_ALLOCATION_METHOD, P_SOURCE_REFRESH_POLICY, P_WARNING_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CLIMATE: Observed climate series, forecast validity and no invented warnings. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load the declared observed series, missing P1 observation, issue/validity forecast and dated plot-crop record.; Select source/period/location, compare only compatible dated observations and advance beyond forecast validity.; Unknown rainfall/location stays unknown; stale forecasts and failed refresh are visible; no official warning is invented.
Expected result: SHARED must link farming activities, problems, actions and evidence to the relevant plot, crop, project and workflow. Compare the exact named value/state/link in FIX-CLIMATE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR081-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR081.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: dated source series; forecast/refresh detail; domain comparison
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-001-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Each geographic record type must identify its owning institution, domain, subject, business object, allowed geometry, required and optional fields, place and time rules, source and evidence, validation, review workflow, map style, classification and access. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-001-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Authorised stewards configure the type through the shared definitions. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-001-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-001.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-002-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Authorised users must select the domain and record type, then choose an existing area or feature, enter coordinates, drop a point, or draw a line, polygon or supported multipart feature. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-002-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Show only applicable fields and save the geometry or reference as a draft with the related business information. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-002-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-002.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-003-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Keep a known administrative area separate from the actual occurrence or affected extent. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-003-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Allow an area-only record when a precise location is unknown. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-003-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Retain positional accuracy, uncertainty and source description for approximate points. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-003-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Never invent coordinates, centroids or polygons to satisfy a field. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-003-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-003.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-004-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: One record may have several geographic representations: reported location, observed extent, surveyed footprint, investigation area, model assessment, proposed intervention and monitoring area. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-004-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Each representation must retain its role, source, applicable period, accuracy and version. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-004-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Do not silently combine these roles. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-004-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-004.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-005-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Use the domain owner's published field definitions and reuse equivalent fields. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-005-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Incident, wildlife, crop suitability and other record types may need different attributes and review rules. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-005-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: The owner confirms the field meanings, required state, units and allowed values before publication. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-005-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-005.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-006-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Support approved manual drawing, field and mobile surveys, coordinate entry, existing feature selection, GIS imports, institutional APIs and remote-sensing products. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-006-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: AI-suggested geographic references require the approved document-processing route. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-006-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Every route uses shared source registration, mapping, validation and review. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-006-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-006.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-007-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: unrecognised or missing CRS; never silently transform it. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused coordinate system variation: unrecognised or missing CRS; never silently transform it.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared coordinate system rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: reverse the declared axes, including an out-of-range latitude variation. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused axis order variation: reverse the declared axes, including an out-of-range latitude variation.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared axis order rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: coordinates [181,91]. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused ranges variation: coordinates [181,91].; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared ranges rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: Point submitted to a type allowing only Polygon. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused geometry type variation: Point submitted to a type allowing only Polygon.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared geometry type rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C05-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: emptyGeometry from FIX-GEOMETRY. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused empty shapes variation: emptyGeometry from FIX-GEOMETRY.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared empty shapes rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C06-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: unclosedPolygon from FIX-GEOMETRY. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused polygon closure variation: unclosedPolygon from FIX-GEOMETRY.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared polygon closure rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C07-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: selfIntersectingPolygon from FIX-GEOMETRY. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused self-intersection variation: selfIntersectingPolygon from FIX-GEOMETRY.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared self-intersection rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C08-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: the self-intersecting polygon and configured topology violation. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused topology variation: the self-intersecting polygon and configured topology violation.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared topology rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C09-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: valid global coordinate outside the accepted local fixture extent. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused extent variation: valid global coordinate outside the accepted local fixture extent.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared extent rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C10-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: unparseable observation time; also test the accepted period rule boundaries. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused time variation: unparseable observation time; also test the accepted period rule boundaries.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared time rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C11-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: a mass unit supplied to the declared area field. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused units variation: a mass unit supplied to the declared area field.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared units rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C12-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: omit one field named in P_REQUIRED_FIELDS. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused required fields variation: omit one field named in P_REQUIRED_FIELDS.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared required fields rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C13-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: replay SYN-GEO-CMD-A unchanged, then change content under the same ID. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused duplicate submissions variation: replay SYN-GEO-CMD-A unchanged, then change content under the same ID.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared duplicate submissions rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C14-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: missing or differently scoped SYN-OBJECT-A reference. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused object relationships variation: missing or differently scoped SYN-OBJECT-A reference.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared object relationships rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C15-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: missing, changed or ineligible exact SYN-SOURCE-A@v1 binding. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused source version variation: missing, changed or ineligible exact SYN-SOURCE-A@v1 binding.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared source version rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C16-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: V_MAX−1,V_MAX,V_MAX+1 using accepted complexity rules. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused complexity limits variation: V_MAX−1,V_MAX,V_MAX+1 using accepted complexity rules.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared complexity limits rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-C17-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY; validPoint/validPolygon baseline; variation: each supported invalid field variation; inspect its safe field-level correction. Limits are execution parameters, not invented scientific thresholds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1, source v1, related object and the declared fixture-only geometry context.; Submit the valid geometry and retain its draft/result.; Submit the focused correction details variation: each supported invalid field variation; inspect its safe field-level correction.; Compare validation paths/messages and retained record state. Reopen the original valid draft and its source/history.
Expected result: Apply the declared correction details rule exactly. Reject unsupported/invalid input with clear safe correction; no invented geometry, unit, source, partial write or false success. Replay handling preserves one outcome where required.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-007-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-007.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-008-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Reviewers must inspect the submitted geometry, original source, field mappings, accuracy, related records, existing layers, validation, earlier versions and evidence. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-008-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Record acceptance, return, rejection or required correction under the approved workflow. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-008-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Technical validity alone cannot approve a geographic feature. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-008-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-008.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-009-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Preserve the source institution, custodian, classification and permitted audience of every geographic claim. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-009-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Different institutions may report on the same occurrence. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-009-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Reviewed matching may link the reports without deleting originals or transferring ownership. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-009-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-009.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-010-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Preserve corrections, earlier geometry versions and reasons. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-010-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: A later surveyed footprint links to the original approximate record. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-010-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Authorised users can inspect the historical evidence and change history. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-010-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-010.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-011-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Keep occurrence, observation, reporting, survey, assessment, validity, entry and revision times distinct where relevant. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-011-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Allow historical and reporting-period filters. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-011-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: A past flood extent must not be displayed as a current flood simply because its record is opened. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-011-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-011.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-012-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Expose permitted accepted records through the shared Map Explorer and spatial catalogue. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-012-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Reuse existing layers, styles, geography references and services. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-012-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Use governed feature collections where appropriate rather than a new catalogue, engine or physical layer for every institution or event. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-012-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-012.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-013-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Configure symbols, legends and styles for record types and geographic roles. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-013-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Distinguish incidents, surveyed extents, suitability assessments, proposed interventions and unreviewed observations. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-013-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Colour alone must not communicate approval, severity, hazard or suitability. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-013-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-013.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-014-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Permit supported area, distance, overlap, intersection, containment, proximity, administrative aggregation, temporal comparison, counts and overlay analyses. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-014-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Retain the actual source geometry, method, units, limits and derived-result evidence. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-014-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Do not imply unsupported scientific accuracy. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-014-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-014.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-015-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Reuse the same accepted geographic identity across permitted map, location profile, domain dashboard, expert, planning, decision, project and PMU views. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-015-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Links must preserve the governed source, version and access rules. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-015-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-015.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-016-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Provide the appropriate authorised edit, field survey, API, GIS import or source-synchronisation route for each record or layer. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-016-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Preserve source and geometry history. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-016-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Operational users must not edit database records directly. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-016-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-016.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-017-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Within the agreed responsive field journey, allow authorised users to capture geographic points, accuracy, permitted geometry, photographs and actual observation time where the selected device supports them. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-017-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: An additional field-access channel and offline drafts are proposed options under C01, C06 and C07. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-017-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: If selected, protect drafts and synchronise through the common authenticated service interfaces. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-017-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Synchronisation alone must not publish an unreviewed record. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-017-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-017.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-018-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Show source, actual observation or occurrence time, geometry role, accuracy, review and approval state, version and real, reference or demonstration origin in maps and record details. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-018-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Keep unavailable information explicitly unknown. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-018-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-018.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-019-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Apply complete institutional ownership and permission rules to geographic features, service responses, maps, search, counts and exports. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: public list/search; public detail; public map; public count; dependent cache; public export; permitted internal detail/history
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-019-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Protect sensitive wildlife locations, personal information and restricted records. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: public list/search; public detail; public map; public count; dependent cache; public export; permitted internal detail/history
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-019-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: For fresh public access, use one shared eligibility rule for publication state, classification, audience, required source identity, exact permitted source version, approved use rights, expiry and source or citation dependencies. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: public list/search; public detail; public map; public count; dependent cache; public export; permitted internal detail/history
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-019-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Re-evaluate on read and export, including dependent cached outputs. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: public list/search; public detail; public map; public count; dependent cache; public export; permitted internal detail/history
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-019-C05-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Suppress public access when a required dependency is withdrawn, expired, restricted, missing, cyclic or no longer authorised for the requested use. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: public list/search; public detail; public map; public count; dependent cache; public export; permitted internal detail/history
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-019-C06-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Do not assume the newest version is approved or reject an older version that remains explicitly permitted. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: public list/search; public detail; public map; public count; dependent cache; public export; permitted internal detail/history
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-019-C07-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Preserve authorised internal records, provenance and history. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: public list/search; public detail; public map; public count; dependent cache; public export; permitted internal detail/history
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-019-C08-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Previously downloaded copies outside SHARED cannot be recalled. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: public list/search; public detail; public map; public count; dependent cache; public export; permitted internal detail/history
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-019-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-019.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: public list/search; public detail; public map; public count; dependent cache; public export; permitted internal detail/history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SH-GEO-FEAT-020-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Distinguish reported from verified landslides, thermal detections from confirmed fires, forecasts from observed flood extents, suitability scores from legal land-use decisions, proposed from implemented activities, and exploratory from accepted scientific results. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-020-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed geography/source custodians and institutional data owners; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-GEOMETRY with explicit versions and accepted parameters: P_ALLOWED_CRS, P_AXIS_ORDER, P_GEOMETRY_ROLE, P_TYPE_GEOMETRIES, P_TOPOLOGY_RULE, P_MAX_VERTICES_V, P_QUERY_LIMIT_Q, P_TIME_RULE, P_REQUIRED_FIELDS, P_ACCEPTED_SOURCE_VERSION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-GEOMETRY: Controlled synthetic geometry and geographic validation. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Configure SYN-TYPE-A@v1 and the fixture-only CRS/extent; create SYN-OBJECT-A and source v1.; Submit the valid geometry, then the focused invalid geometry or reference variation.; Compare field-level correction details and saved geometry/source/history; no invalid or invented location is accepted.
Expected result: Official warnings, regulatory decisions and expert conclusions require their own authority and approval. Compare the exact named value/state/link in FIX-GEOMETRY under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
SH-GEO-FEAT-020-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#geo-module; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against SH-GEO-FEAT-020.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: geographic record form; validation result; record/map detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR094-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REPORT with explicit versions and accepted parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS, P_EXACT_INPUT_VERSIONS, P_APPROVED_JOIN_TYPE, P_MISSING_ROW_POLICY, P_EXPORT_PUBLICATION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REPORT: Explicit report grain, joins, missing rows and reproducible export. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register sourceA/sourceB versions and the declared one-row-per-key P0 grain.; Build SYN-REPORT-A@v1 using the accepted join/filter plan; run/export it, then add the duplicate-key variation.; Preserve unmatched/zero rows under policy, reject unsupported duplication and reconcile saved result/table/export lineage.
Expected result: SHARED must allow permitted users to select bounded approved templates, fields, filters and aggregations. Compare the exact named value/state/link in FIX-REPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR094-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REPORT with explicit versions and accepted parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS, P_EXACT_INPUT_VERSIONS, P_APPROVED_JOIN_TYPE, P_MISSING_ROW_POLICY, P_EXPORT_PUBLICATION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REPORT: Explicit report grain, joins, missing rows and reproducible export. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register sourceA/sourceB versions and the declared one-row-per-key P0 grain.; Build SYN-REPORT-A@v1 using the accepted join/filter plan; run/export it, then add the duplicate-key variation.; Preserve unmatched/zero rows under policy, reject unsupported duplication and reconcile saved result/table/export lineage.
Expected result: Do not accept raw database commands, scripts or arbitrary executable formulas. Compare the exact named value/state/link in FIX-REPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR094-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#reports-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR094.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR095-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REPORT with explicit versions and accepted parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS, P_EXACT_INPUT_VERSIONS, P_APPROVED_JOIN_TYPE, P_MISSING_ROW_POLICY, P_EXPORT_PUBLICATION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REPORT: Explicit report grain, joins, missing rows and reproducible export. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register sourceA/sourceB versions and the declared one-row-per-key P0 grain.; Build SYN-REPORT-A@v1 using the accepted join/filter plan; run/export it, then add the duplicate-key variation.; Preserve unmatched/zero rows under policy, reject unsupported duplication and reconcile saved result/table/export lineage.
Expected result: SHARED must retain source and version, time, scope and reproducible inputs for queries and executions. Compare the exact named value/state/link in FIX-REPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR095-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REPORT with explicit versions and accepted parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS, P_EXACT_INPUT_VERSIONS, P_APPROVED_JOIN_TYPE, P_MISSING_ROW_POLICY, P_EXPORT_PUBLICATION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REPORT: Explicit report grain, joins, missing rows and reproducible export. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register sourceA/sourceB versions and the declared one-row-per-key P0 grain.; Build SYN-REPORT-A@v1 using the accepted join/filter plan; run/export it, then add the duplicate-key variation.; Preserve unmatched/zero rows under policy, reject unsupported duplication and reconcile saved result/table/export lineage.
Expected result: Export and later reads must recheck permission. Compare the exact named value/state/link in FIX-REPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR096-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REPORT with explicit versions and accepted parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS, P_EXACT_INPUT_VERSIONS, P_APPROVED_JOIN_TYPE, P_MISSING_ROW_POLICY, P_EXPORT_PUBLICATION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REPORT: Explicit report grain, joins, missing rows and reproducible export. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register sourceA/sourceB versions and the declared one-row-per-key P0 grain.; Build SYN-REPORT-A@v1 using the accepted join/filter plan; run/export it, then add the duplicate-key variation.; Preserve unmatched/zero rows under policy, reject unsupported duplication and reconcile saved result/table/export lineage.
Expected result: SHARED must retain a versioned join plan identifying exact input versions, keys, number of matching records, time alignment, meaning of one output row, missing-row policy, purpose and evidence. Compare the exact named value/state/link in FIX-REPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR096-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#reports-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR096.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR097-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REPORT with explicit versions and accepted parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS, P_EXACT_INPUT_VERSIONS, P_APPROVED_JOIN_TYPE, P_MISSING_ROW_POLICY, P_EXPORT_PUBLICATION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REPORT: Explicit report grain, joins, missing rows and reproducible export. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register sourceA/sourceB versions and the declared one-row-per-key P0 grain.; Build SYN-REPORT-A@v1 using the accepted join/filter plan; run/export it, then add the duplicate-key variation.; Preserve unmatched/zero rows under policy, reject unsupported duplication and reconcile saved result/table/export lineage.
Expected result: SHARED must preserve unmatched rows and mapping or approval checks when joining datasets. Compare the exact named value/state/link in FIX-REPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR097-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REPORT with explicit versions and accepted parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS, P_EXACT_INPUT_VERSIONS, P_APPROVED_JOIN_TYPE, P_MISSING_ROW_POLICY, P_EXPORT_PUBLICATION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REPORT: Explicit report grain, joins, missing rows and reproducible export. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register sourceA/sourceB versions and the declared one-row-per-key P0 grain.; Build SYN-REPORT-A@v1 using the accepted join/filter plan; run/export it, then add the duplicate-key variation.; Preserve unmatched/zero rows under policy, reject unsupported duplication and reconcile saved result/table/export lineage.
Expected result: Reject duplicate keys, unsupported joins, changed approval state and work beyond limits. Compare the exact named value/state/link in FIX-REPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR097-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#reports-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR097.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR098-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REPORT with explicit versions and accepted parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS, P_EXACT_INPUT_VERSIONS, P_APPROVED_JOIN_TYPE, P_MISSING_ROW_POLICY, P_EXPORT_PUBLICATION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REPORT: Explicit report grain, joins, missing rows and reproducible export. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register sourceA/sourceB versions and the declared one-row-per-key P0 grain.; Build SYN-REPORT-A@v1 using the accepted join/filter plan; run/export it, then add the duplicate-key variation.; Preserve unmatched/zero rows under policy, reject unsupported duplication and reconcile saved result/table/export lineage.
Expected result: SHARED must reuse private versioned report definitions and saved report runs, retaining exact source values, units, filters, review and calculation. Compare the exact named value/state/link in FIX-REPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR098-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REPORT with explicit versions and accepted parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS, P_EXACT_INPUT_VERSIONS, P_APPROVED_JOIN_TYPE, P_MISSING_ROW_POLICY, P_EXPORT_PUBLICATION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REPORT: Explicit report grain, joins, missing rows and reproducible export. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register sourceA/sourceB versions and the declared one-row-per-key P0 grain.; Build SYN-REPORT-A@v1 using the accepted join/filter plan; run/export it, then add the duplicate-key variation.; Preserve unmatched/zero rows under policy, reject unsupported duplication and reconcile saved result/table/export lineage.
Expected result: Editing or refreshing creates a new version or execution. Compare the exact named value/state/link in FIX-REPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR098-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#reports-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR098.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR099-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REPORT with explicit versions and accepted parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS, P_EXACT_INPUT_VERSIONS, P_APPROVED_JOIN_TYPE, P_MISSING_ROW_POLICY, P_EXPORT_PUBLICATION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REPORT: Explicit report grain, joins, missing rows and reproducible export. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register sourceA/sourceB versions and the declared one-row-per-key P0 grain.; Build SYN-REPORT-A@v1 using the accepted join/filter plan; run/export it, then add the duplicate-key variation.; Preserve unmatched/zero rows under policy, reject unsupported duplication and reconcile saved result/table/export lineage.
Expected result: SHARED must use suitable comparisons, date series and distributions with units and source coverage. Compare the exact named value/state/link in FIX-REPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR099-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#reports-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR099.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR100-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REPORT with explicit versions and accepted parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS, P_EXACT_INPUT_VERSIONS, P_APPROVED_JOIN_TYPE, P_MISSING_ROW_POLICY, P_EXPORT_PUBLICATION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REPORT: Explicit report grain, joins, missing rows and reproducible export. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register sourceA/sourceB versions and the declared one-row-per-key P0 grain.; Build SYN-REPORT-A@v1 using the accepted join/filter plan; run/export it, then add the duplicate-key variation.; Preserve unmatched/zero rows under policy, reject unsupported duplication and reconcile saved result/table/export lineage.
Expected result: SHARED must retain source and review evidence in supported spreadsheet, CSV, JSON and print outputs. Compare the exact named value/state/link in FIX-REPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR100-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REPORT with explicit versions and accepted parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS, P_EXACT_INPUT_VERSIONS, P_APPROVED_JOIN_TYPE, P_MISSING_ROW_POLICY, P_EXPORT_PUBLICATION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REPORT: Explicit report grain, joins, missing rows and reproducible export. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register sourceA/sourceB versions and the declared one-row-per-key P0 grain.; Build SYN-REPORT-A@v1 using the accepted join/filter plan; run/export it, then add the duplicate-key variation.; Preserve unmatched/zero rows under policy, reject unsupported duplication and reconcile saved result/table/export lineage.
Expected result: Formal report versions use saved results, list of supporting evidences and reviewed publication. Compare the exact named value/state/link in FIX-REPORT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR100-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#reports-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR100.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: report definition; saved result/table; permitted export
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR101-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: SHARED must show each decision question, exact context, required data, method, authority and outcome-monitoring needs. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR101-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: Missing data, expert decisions and governance approval must have named owners. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR101-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#dashboard-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR101.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR102-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: SHARED must use explicit reviewed weights, best/worst anchors, exact source units and required values in the criteria calculation within defined limits. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR102-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: Missing evidence blocks the score. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR102-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: equal scores keep equal rank. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR102-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#dashboard-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR102.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR103-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: SHARED must check compatible unit, place and period before plan/actual arithmetic and withhold percentage variance when the plan is zero. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR103-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: Numeric rule checks require explicit reviewed thresholds and output meaning. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR103-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#dashboard-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR103.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR104-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: SHARED must allow an approved enabled routing policy to create a shared review case with named people, severity and deadline. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR104-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: Case creation and result publication must succeed or fail together. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR105-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: SHARED must retain each case's problem, evidence, assignment, options, consultation, recommendation, authority, rationale, actions, outcome verification and closure or reopening history. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR105-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#dashboard-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR105.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR106-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: SHARED must use actual permitted records for decision preparation. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR106-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: When considering which option fits the local circumstances, SHARED must reuse current independently reviewed published knowledge and exact case citations. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR106-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#dashboard-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR106.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR107-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: SHARED must enforce required independence between decision roles. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR107-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Report/decision owner and proposed method/data reviewers; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-DECISION with explicit versions and accepted parameters: P_METHOD_VERSION, P_REVIEWED_WEIGHTS_ANCHORS, P_UNIT_PLACE_PERIOD, P_AUTHORITY_INDEPENDENCE, P_ROUTING_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-DECISION: Evidence-linked option comparison, authority and action follow-up. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create SYN-DECISION-A with source/knowledge citations and two options under the accepted method version.; Compare equal compatible inputs and a missing-input/zero-plan variation; record recommendation and separate authority/action.; Ties remain tied, missing evidence blocks the score, zero-plan percentage remains unavailable and no legal/payment authority is inferred.
Expected result: Generic scoring and policy checks must not claim scientific suitability, legal eligibility, entitlement or payment authority. Compare the exact named value/state/link in FIX-DECISION under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR107-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#dashboard-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR107.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: decision/option form; comparison result; decision/action history
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR108-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must keep project type, funder, lead, partners, objectives, dates, lifecycle state and reporting obligations within permitted scope. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR108-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR108.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR109-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must link one project to several domains and places through explicit applicability relationships tied to that project revision. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR109-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR109.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR110-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must maintain components, activities, interventions, sites, responsible organizations, schedules and implementation state. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR110-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR110.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR111-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must preserve source and access rules when linking projects or interventions to documents, datasets, indicators, layers, submissions and evidence. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR111-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR111.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR112-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must retain a reviewed source baseline, original project identifier, baseline date and known quality findings when onboarding an ongoing or completed project. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR112-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: The import must preserve known history without inventing milestones. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR112-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR112.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR113-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must create linked revisions for material changes to active projects instead of overwriting approved project or domain profiles. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR113-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR113.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR114-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must use one persisted plan from intake and configuration through review, activation, execution, monitoring, decision, reporting, closure and archive. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR114-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR114.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR115-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must distinguish setting up a new project from importing an ongoing or completed project. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR115-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Each applicable step must keep status, owner, due date, dependencies, validation and completion evidence. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR115-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR115.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR116-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must keep obligation definition, occurrence, fixed submitted version, schema section, artifact and review decision separately linked. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR116-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR116.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR117-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must support one-time and recurring obligations. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR117-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Generate occurrences repeatably and derive overdue from the actual due date and state. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR117-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR117.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR118-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must record each assignment's responsible organization, group or person, component, domain, geography, dates, dependencies, acceptance criteria, authority and evidence needs. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR118-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR118.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR119-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must validate against the original form version. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR119-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Retain review findings, return reasons, corrected versions and resubmission. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR119-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Blocking findings must prevent acceptance. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR119-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR119.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR120-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must prevent My work and review queues from disclosing differently scoped work through lists, counts, maps, files or exports. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR121-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must use configured reviewer assignments and retained decisions. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR121-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Protect high-impact publication, role, geography, taxonomy and import changes with independent approval. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR121-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR121.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR122-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must link an exact permitted feedback submission to the shared decision case with compatible revision, domain and place. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR122-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Keep original content, review and later response evidence. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR122-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR122.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR123-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must retain reviewed indicators, baseline, target, period, place, responsibility, sources, calculation, quality and approval for each active project-domain monitoring context. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR123-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR123.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR124-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must support unknown or descriptive baselines where permitted, dated targets, denominators, assumptions and verification needs. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR124-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Keep targets separate from observed results. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR124-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR124.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR125-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must generate monitoring results only through approved versioned calculations. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR125-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Keep exact input and output history, steps, units, parameters, review and execution evidence. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR125-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR125.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR126-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must reconcile delivery, monitoring, decisions, data, access, knowledge, handover, retention and post-project obligations during required closure. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR126-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR126.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR127-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must record each closure check's owner, deadline, evidence and independent verification or permitted reasoned waiver. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR127-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Retain unchangeable status history. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR127-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR127.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR128-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: SHARED must enforce the approved closure plan and frozen list of required closure checks before a project becomes Closed or Archived. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR128-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-PROJECT with explicit versions and accepted parameters: P_ACCEPTED_COMPONENT_SCOPE, P_FORM_SCHEMA_VERSION, P_DUE_DATE, P_REQUIRED_EVIDENCE, P_ACCEPTED_INDICATOR_METHOD, P_FROZEN_CLOSURE_CHECKS. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-PROJECT: Project revisions, obligations, indicator evidence and closure. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: This gate applies through every supported service operation. Compare the exact named value/state/link in FIX-PROJECT under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR128-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR128.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: project/task/obligation form; review queue; monitoring/closure detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR090-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: SHARED must extend shared structure or intervention records with asset profiles. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR090-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: Keep condition, capacity, custody and directed source-reported connections with evidence. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR090-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR090.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR091-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU/M&E and implementing institution owners; named authority and project-tool boundary pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: SHARED must link asset handover and maintenance responsibilities to the required receiving-institution evidence and shared closure process. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR091-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR091.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR086-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: SHARED must extend shared identities with programme participant profiles. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR086-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: retain their owner, domain, geography, source and origin. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR086-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: Keep shared departmental accounts separate from individual beneficiaries. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR086-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR086.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR087-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: SHARED must retain support episodes with their programme, provider, type, source-reported status and known amounts, currency, quantities and dates. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR087-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: Prior-assistance checks must respect lawful access. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR087-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR087.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR088-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: SHARED must reuse shared product, production, producer and named buyer-demand records, retaining their source, units, period and place. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR088-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR088.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR089-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: SHARED must record the definition, period, evidence and denominator for each employment, income, training, women/youth participation or other outcome. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR089-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: A population count is not programme participation. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR089-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR089.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR129-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: SHARED must keep evidence descriptive information, checksum, classification, version and review/publication state with controlled project, domain and location links. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR129-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR129.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR130-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: SHARED must store originals that cannot be changed and controlled previews outside public web folders. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR130-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: Replacement must create a new version. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR131-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: SHARED must enforce size, type, signature, renamed storage, quarantine and genuine malware checks before publication. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download; permitted export
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR131-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: Reauthorize preview, download and export. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download; permitted export
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR131-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: expire temporary links where relevant. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download; permitted export
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR132-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: SHARED must enforce knowledge authoring, independent review, publication, replacement by a newer version, retention and archive stages. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR132-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: Keep earlier versions unchanged. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR132-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR132.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR133-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: SHARED must link knowledge to permitted projects, areas, sources, evidence, results, decisions and deliverables. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR133-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: Recheck restricted or withdrawn citations without leaking descriptive information. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR133-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR133.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR134-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: SHARED must let public readers find eligible local information, options, opportunities and project activities without an account. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR134-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: Signed-in readers must retain an uncomplicated public view. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR134-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR134.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR135-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: SHARED must keep protected feedback separate from public grievances. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR135-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed institutional service/knowledge owner and publication reviewer; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-KNOWLEDGE with explicit versions and accepted parameters: P_FILE_SIZE_TYPE_POLICY, P_GENUINE_SCAN_RECEIPT, P_PUBLICATION_AUTHORITY, P_RECEIVER_MODERATION_APPEAL, P_RETENTION_POLICY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-KNOWLEDGE: Protected originals, evidence versions, publication and feedback. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Register the safe synthetic original with owner, checksum, class and linked source; keep it outside public storage.; Create a replacement/review/publication or protected feedback action appropriate to the clause.; Reauthorise each read/download; preserve original versions and keep unclean, restricted or unreviewed evidence unpublished.
Expected result: Public activation needs a recorded policy covering receiver, deadlines, independent appeal, privacy, safeguarding and abuse controls. Compare the exact named value/state/link in FIX-KNOWLEDGE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-PUBLIC-ALLOW; SC-PUBLIC-WITHDRAW; SC-PUBLIC-OLDVERSION
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR135-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR135.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: evidence/knowledge list; permitted detail/preview; permitted download
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR082-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: SHARED must retain product, quantity, unit, dates, currency, source and scope for harvest batches, buyers, sales and recorded sale-payment evidence. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR082-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: Recording evidence is not executing a payment. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR082-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR082.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR083-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: SHARED must retain a source-supported origin assertion for the particular record and expire the assertion when the supporting facts change. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR083-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: Complete unknown currency through authorized evidence without changing amounts or an established currency silently. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR083-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR083.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR084-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: SHARED must retain exact product, unit, origin, periods, row versions and comparison time when comparing production and demand. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR084-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: Different periods must not produce a misleading quantity difference. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR084-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR084.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR085-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: SHARED must use reviewed formula versions and exact compatible inputs for seasonal production, cost, revenue, margin and break-even outputs. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR085-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: Unknown costs, yield assumptions, currencies and season definitions must block the affected result or appear as explicitly incomplete. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR085-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR085.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR092-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: SHARED must retain the owner and authority of PES schemes, agreements, service verification and source-reported payment-stage evidence. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR092-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: Missing rates, eligibility, appeals or legal approval must not be invented. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR092-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR092.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR093-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: Proposed sector/programme data owner and method specialist; named authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-MARKET with explicit versions and accepted parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY, P_APPROVED_FORMULA_VERSION, P_ELIGIBILITY_RATE_AUTHORITY, P_PAYMENT_STAGE_VOCABULARY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-MARKET: Compatible production, demand, margin and payment evidence. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Create the synthetic harvest, demand, cost and evidence records with exact product, kg, P0 and declared currency.; Compare compatible P0 records, then vary period/unit/currency or omit a required cost/method/authority.; Reconcile compatible outputs, block misleading differences and keep recorded payment/PES evidence distinct from execution.
Expected result: SHARED must connect permitted support, product, asset, market, outcome and evidence records in analysis while preserving source versions and original scope. Compare the exact named value/state/link in FIX-MARKET under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR093-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR093.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: product/market/PES form; comparison/evidence detail
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR136-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: SHARED must provide a web application that uses the published service contracts, secure server-side sessions, anti-forgery protection and secure cookies. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR136-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: It must never access database tables directly. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR137-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: SHARED must use guided steps, searchable choices, progressive details and clear loading, empty, error and denied states. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR137-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: Validate responsive, keyboard and accessibility behaviour on the agreed matrix. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR137-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR137.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR138-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REFERENCE with explicit versions and accepted parameters: P_AGREED_LANGUAGE_SCOPE, P_APPROVED_TERM_EDITION, P_REQUIRED_RESOURCE_KEYS, P_APPOINTED_REVIEW_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REFERENCE; reference edition SYN-REF-v1; allowed A/B choice IDs; unknown choice C; focus=authoritative reference choices.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load SYN-REF-v1 and the accepted language/resource-key scope.; Open the form in the focused language or reference-data mode; compare IDs/labels/errors with that exact edition.; Inject SYN-CHOICE-C or omit a required translated key and inspect rejection/incomplete status.; Attempt release without the required appointed terminology decision; keep it pending until valid authority evidence is supplied in the isolated future test.
Expected result: Use authorised stable choice IDs and complete agreed authoritative reference choices resources. Unsupported/injected choices are rejected. Proposed translations or demo reviews do not become client acceptance.
Output paths: authorised reference choices; English resources; Sinhala resources; Tamil resources; terminology review gate
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR138-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REFERENCE with explicit versions and accepted parameters: P_AGREED_LANGUAGE_SCOPE, P_APPROVED_TERM_EDITION, P_REQUIRED_RESOURCE_KEYS, P_APPOINTED_REVIEW_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REFERENCE; reference edition SYN-REF-v1; allowed A/B choice IDs; unknown choice C; focus=English.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load SYN-REF-v1 and the accepted language/resource-key scope.; Open the form in the focused language or reference-data mode; compare IDs/labels/errors with that exact edition.; Inject SYN-CHOICE-C or omit a required translated key and inspect rejection/incomplete status.; Attempt release without the required appointed terminology decision; keep it pending until valid authority evidence is supplied in the isolated future test.
Expected result: Use authorised stable choice IDs and complete agreed English resources. Unsupported/injected choices are rejected. Proposed translations or demo reviews do not become client acceptance.
Output paths: authorised reference choices; English resources; Sinhala resources; Tamil resources; terminology review gate
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR138-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REFERENCE with explicit versions and accepted parameters: P_AGREED_LANGUAGE_SCOPE, P_APPROVED_TERM_EDITION, P_REQUIRED_RESOURCE_KEYS, P_APPOINTED_REVIEW_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REFERENCE; reference edition SYN-REF-v1; allowed A/B choice IDs; unknown choice C; focus=Sinhala.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load SYN-REF-v1 and the accepted language/resource-key scope.; Open the form in the focused language or reference-data mode; compare IDs/labels/errors with that exact edition.; Inject SYN-CHOICE-C or omit a required translated key and inspect rejection/incomplete status.; Attempt release without the required appointed terminology decision; keep it pending until valid authority evidence is supplied in the isolated future test.
Expected result: Use authorised stable choice IDs and complete agreed Sinhala resources. Unsupported/injected choices are rejected. Proposed translations or demo reviews do not become client acceptance.
Output paths: authorised reference choices; English resources; Sinhala resources; Tamil resources; terminology review gate
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR138-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REFERENCE with explicit versions and accepted parameters: P_AGREED_LANGUAGE_SCOPE, P_APPROVED_TERM_EDITION, P_REQUIRED_RESOURCE_KEYS, P_APPOINTED_REVIEW_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REFERENCE; reference edition SYN-REF-v1; allowed A/B choice IDs; unknown choice C; focus=Tamil.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load SYN-REF-v1 and the accepted language/resource-key scope.; Open the form in the focused language or reference-data mode; compare IDs/labels/errors with that exact edition.; Inject SYN-CHOICE-C or omit a required translated key and inspect rejection/incomplete status.; Attempt release without the required appointed terminology decision; keep it pending until valid authority evidence is supplied in the isolated future test.
Expected result: Use authorised stable choice IDs and complete agreed Tamil resources. Unsupported/injected choices are rejected. Proposed translations or demo reviews do not become client acceptance.
Output paths: authorised reference choices; English resources; Sinhala resources; Tamil resources; terminology review gate
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR138-C05-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-REFERENCE with explicit versions and accepted parameters: P_AGREED_LANGUAGE_SCOPE, P_APPROVED_TERM_EDITION, P_REQUIRED_RESOURCE_KEYS, P_APPOINTED_REVIEW_AUTHORITY. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-REFERENCE; reference edition SYN-REF-v1; allowed A/B choice IDs; unknown choice C; focus=independent terminology acceptance.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Load SYN-REF-v1 and the accepted language/resource-key scope.; Open the form in the focused language or reference-data mode; compare IDs/labels/errors with that exact edition.; Inject SYN-CHOICE-C or omit a required translated key and inspect rejection/incomplete status.; Attempt release without the required appointed terminology decision; keep it pending until valid authority evidence is supplied in the isolated future test.
Expected result: Use authorised stable choice IDs and complete agreed independent terminology acceptance resources. Unsupported/injected choices are rejected. Proposed translations or demo reviews do not become client acceptance.
Output paths: authorised reference choices; English resources; Sinhala resources; Tamil resources; terminology review gate
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR138-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR138.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: authorised reference choices; English resources; Sinhala resources; Tamil resources; terminology review gate
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR139-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: SHARED must use environment-safe configuration and the same authenticated service interfaces across approved access channels. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR139-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: Each channel must protect credentials and session material using approved secure facilities. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR139-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: enforce rotation, revocation, expiry and logout. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR139-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: An additional field-access channel is a proposed option under C01, C06 and C07, not an accepted first-release commitment. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR140-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: Through the responsive core interface, SHARED must allow permitted users to browse assigned projects, domains, places and maps and capture authorised location, source, accuracy, observation time and evidence. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR140-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: An additional field-access channel or local draft-storage capability is conditional on C01, C06 and C07. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR140-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: When local drafts are permitted, protect them under the approved encryption, retention and privacy rules. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR141-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: If offline operation is selected under C01, C06 and C07, SHARED must protect downloaded authorised assignments, local drafts and evidence under the agreed retention and privacy rules. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR141-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: Show pending, sending, received, rejected and conflict states. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR141-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: Synchronise through the common authenticated service interfaces using stable retry identifiers. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR141-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: Offline operation remains a proposed option until the client accepts its scope. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-STATE-VALID; SC-STATE-INVALID; SC-RETRY-SAME; SC-RETRY-CRASH; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR142-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: SHARED must retain a clear system explanation and role-based user guidance linked to the relevant permitted workflow. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR142-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: The prototype presentation and diagrams support this explanation. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR142-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-CHANNEL with explicit versions and accepted parameters: P_APPROVED_CORE_JOURNEYS, P_DEVICE_LANGUAGE_MATRIX, P_CHANNEL_SELECTION, P_LOCAL_STORAGE_PERMISSION, P_RETENTION_ENCRYPTION_POLICY, P_OFFLINE_SELECTION. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-CHANNEL: Responsive core and explicitly conditional additional/offline channel. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Open the responsive core journey for SYN-FIELD-ASSIGNMENT-A under the accepted device/language matrix.; Browse/capture SYN-DRAFT-A through the permitted journey; exercise extra/local/offline behavior only when selected.; Compare source/accuracy/time, protected state and retry outcome; unreviewed submissions never publish automatically.
Expected result: A demonstration link does not grant access or establish operational acceptance. Compare the exact named value/state/link in FIX-CHANNEL under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR142-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR142.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: responsive sign-in/list/detail/form; draft/submission state
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR143-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE: Transport, origin, header, input and resource checks. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Expose only the isolated SYN-CONTRACT-v1 operations under the approved test policy.; Send an allowed request, then the focused insecure, disallowed-origin, oversized or unauthorised variation.; Compare safe status/error references and unchanged records; inspect redacted diagnostics for leakage.
Expected result: SHARED must use versioned API routes and explicit request/response contracts with an accurate API description. Compare the exact named value/state/link in FIX-INTERFACE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR143-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE: Transport, origin, header, input and resource checks. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Expose only the isolated SYN-CONTRACT-v1 operations under the approved test policy.; Send an allowed request, then the focused insecure, disallowed-origin, oversized or unauthorised variation.; Compare safe status/error references and unchanged records; inspect redacted diagnostics for leakage.
Expected result: Reject unsupported request properties. Compare the exact named value/state/link in FIX-INTERFACE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR144-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE: Transport, origin, header, input and resource checks. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Expose only the isolated SYN-CONTRACT-v1 operations under the approved test policy.; Send an allowed request, then the focused insecure, disallowed-origin, oversized or unauthorised variation.; Compare safe status/error references and unchanged records; inspect redacted diagnostics for leakage.
Expected result: SHARED must return consistent safe errors without internal database commands, stack traces or secrets. Compare the exact named value/state/link in FIX-INTERFACE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR144-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE: Transport, origin, header, input and resource checks. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Expose only the isolated SYN-CONTRACT-v1 operations under the approved test policy.; Send an allowed request, then the focused insecure, disallowed-origin, oversized or unauthorised variation.; Compare safe status/error references and unchanged records; inspect redacted diagnostics for leakage.
Expected result: Lists must use deterministic paging, limits, cancellation and timeouts. Compare the exact named value/state/link in FIX-INTERFACE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR144-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR144.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR145-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE: Transport, origin, header, input and resource checks. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Expose only the isolated SYN-CONTRACT-v1 operations under the approved test policy.; Send an allowed request, then the focused insecure, disallowed-origin, oversized or unauthorised variation.; Compare safe status/error references and unchanged records; inspect redacted diagnostics for leakage.
Expected result: Use request references, expected-version checks and stable retry identifiers. Compare the exact named value/state/link in FIX-INTERFACE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR145-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE: Transport, origin, header, input and resource checks. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Expose only the isolated SYN-CONTRACT-v1 operations under the approved test policy.; Send an allowed request, then the focused insecure, disallowed-origin, oversized or unauthorised variation.; Compare safe status/error references and unchanged records; inspect redacted diagnostics for leakage.
Expected result: Limit retries so repeated failures do not overload the service. Compare the exact named value/state/link in FIX-INTERFACE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR145-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE: Transport, origin, header, input and resource checks. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Expose only the isolated SYN-CONTRACT-v1 operations under the approved test policy.; Send an allowed request, then the focused insecure, disallowed-origin, oversized or unauthorised variation.; Compare safe status/error references and unchanged records; inspect redacted diagnostics for leakage.
Expected result: Health checks must use approved service operations. Compare the exact named value/state/link in FIX-INTERFACE under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR145-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR145.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR146-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE; focus=secure transport; SYN-REQUEST-A; allowed/denied reserved test origins; accepted transport/header/rate/input/permission parameters.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Make the permitted SYN-CONTRACT-v1 request for SYN-REC-A under the accepted test policy.; Change only secure transport: use insecure/unsupported transport, omit H, use the denied origin, exceed Q, send invalid input or remove the relevant grant as applicable.; Repeat the focused allowed/boundary/denied variation without altering other permissions.; Inspect response, resource state and redacted diagnostic request reference.
Expected result: Enforce secure transport at the declared boundary. Denied or over-limit work cannot reach the protected action, alter records or disclose secrets; errors follow the safe contract.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR146-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE; focus=required header set H; SYN-REQUEST-A; allowed/denied reserved test origins; accepted transport/header/rate/input/permission parameters.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Make the permitted SYN-CONTRACT-v1 request for SYN-REC-A under the accepted test policy.; Change only required header set H: use insecure/unsupported transport, omit H, use the denied origin, exceed Q, send invalid input or remove the relevant grant as applicable.; Repeat the focused allowed/boundary/denied variation without altering other permissions.; Inspect response, resource state and redacted diagnostic request reference.
Expected result: Enforce required header set H at the declared boundary. Denied or over-limit work cannot reach the protected action, alter records or disclose secrets; errors follow the safe contract.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR146-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE; focus=allowed origins; SYN-REQUEST-A; allowed/denied reserved test origins; accepted transport/header/rate/input/permission parameters.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Make the permitted SYN-CONTRACT-v1 request for SYN-REC-A under the accepted test policy.; Change only allowed origins: use insecure/unsupported transport, omit H, use the denied origin, exceed Q, send invalid input or remove the relevant grant as applicable.; Repeat the focused allowed/boundary/denied variation without altering other permissions.; Inspect response, resource state and redacted diagnostic request reference.
Expected result: Enforce allowed origins at the declared boundary. Denied or over-limit work cannot reach the protected action, alter records or disclose secrets; errors follow the safe contract.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR146-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE; focus=rate limit Q within W; SYN-REQUEST-A; allowed/denied reserved test origins; accepted transport/header/rate/input/permission parameters.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Make the permitted SYN-CONTRACT-v1 request for SYN-REC-A under the accepted test policy.; Change only rate limit Q within W: use insecure/unsupported transport, omit H, use the denied origin, exceed Q, send invalid input or remove the relevant grant as applicable.; Repeat the focused allowed/boundary/denied variation without altering other permissions.; Inspect response, resource state and redacted diagnostic request reference.
Expected result: Enforce rate limit Q within W at the declared boundary. Denied or over-limit work cannot reach the protected action, alter records or disclose secrets; errors follow the safe contract.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR146-C05-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE; focus=input validation; SYN-REQUEST-A; allowed/denied reserved test origins; accepted transport/header/rate/input/permission parameters.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Make the permitted SYN-CONTRACT-v1 request for SYN-REC-A under the accepted test policy.; Change only input validation: use insecure/unsupported transport, omit H, use the denied origin, exceed Q, send invalid input or remove the relevant grant as applicable.; Repeat the focused allowed/boundary/denied variation without altering other permissions.; Inspect response, resource state and redacted diagnostic request reference.
Expected result: Enforce input validation at the declared boundary. Denied or over-limit work cannot reach the protected action, alter records or disclose secrets; errors follow the safe contract.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR146-C06-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE; focus=endpoint action permission; SYN-REQUEST-A; allowed/denied reserved test origins; accepted transport/header/rate/input/permission parameters.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Make the permitted SYN-CONTRACT-v1 request for SYN-REC-A under the accepted test policy.; Change only endpoint action permission: use insecure/unsupported transport, omit H, use the denied origin, exceed Q, send invalid input or remove the relevant grant as applicable.; Repeat the focused allowed/boundary/denied variation without altering other permissions.; Inspect response, resource state and redacted diagnostic request reference.
Expected result: Enforce endpoint action permission at the declared boundary. Denied or over-limit work cannot reach the protected action, alter records or disclose secrets; errors follow the safe contract.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR146-C07-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-INTERFACE with explicit versions and accepted parameters: P_SECURE_TRANSPORT_POLICY, P_REQUIRED_HEADER_SET_H, P_ALLOWED_ORIGIN_SET, P_RATE_LIMIT_Q, P_RATE_WINDOW_W, P_PAYLOAD_LIMIT, P_ENDPOINT_ACTION, P_RESOURCE_GRANT. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-INTERFACE; focus=record permission; SYN-REQUEST-A; allowed/denied reserved test origins; accepted transport/header/rate/input/permission parameters.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Make the permitted SYN-CONTRACT-v1 request for SYN-REC-A under the accepted test policy.; Change only record permission: use insecure/unsupported transport, omit H, use the denied origin, exceed Q, send invalid input or remove the relevant grant as applicable.; Repeat the focused allowed/boundary/denied variation without altering other permissions.; Inspect response, resource state and redacted diagnostic request reference.
Expected result: Enforce record permission at the declared boundary. Denied or over-limit work cannot reach the protected action, alter records or disclose secrets; errors follow the safe contract.
Output paths: service response/error; affected resource outcome; redacted diagnostics
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR155-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: SHARED must keep user-interface responsibilities separate from authenticated application services, shared business rules and controlled data access. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR155-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Clients must not access data-store tables directly. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR155-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Protect configuration, files and process permissions. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR155-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: A separate deployment or hosting topology is a proposed option under C07. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR155-C05-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: select it only after reviewing isolation, operations, recovery, cost and portability. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR147-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: SHARED must perform runtime data access through a controlled server-side data access layer and approved operations, including identity and health checks. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR147-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Runtime principals receive only the necessary permissions. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR147-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Clients never access database tables. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR147-C04-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: The selected database plan must specify the operation catalogue and enforcement evidence. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR148-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: SHARED must record significant actor, action, resource, scope, result, reason, standard time and request reference. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR148-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Trace published data back through source, validation and review. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR01-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client service owner and receiving operator role; actual appointment and authority remain pending.
Configuration: Agreed availability-critical journeys and dependency boundary; routes and probe mix pending C08. Data volume: Not a throughput target; use the agreed release dataset and dependencies. Network: Monitoring locations and reachability checks pending C08. Window: Calendar month of agreed service minutes is the existing proposal.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: The service shall achieve at least 99 percent availability. This is the TOR minimum. Proposed measurement is a calendar month of agreed service minutes, including planned maintenance until an exclusion policy is approved.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR01 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Successful service minutes / agreed service minutes ×100; retain monitoring and incident evidence.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: The service shall achieve at least 99 percent availability. Pass/fail rule: At least 99 percent after the service boundary and measurement rules are approved. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR01-C02-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client service owner and receiving operator role; actual appointment and authority remain pending.
Configuration: Agreed availability-critical journeys and dependency boundary; routes and probe mix pending C08. Data volume: Not a throughput target; use the agreed release dataset and dependencies. Network: Monitoring locations and reachability checks pending C08. Window: Calendar month of agreed service minutes is the existing proposal.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: The service shall achieve at least 99 percent availability. This is the TOR minimum. Proposed measurement is a calendar month of agreed service minutes, including planned maintenance until an exclusion policy is approved.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR01 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Successful service minutes / agreed service minutes ×100; retain monitoring and incident evidence.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: This is the TOR minimum. Pass/fail rule: At least 99 percent after the service boundary and measurement rules are approved. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR01-C03-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client service owner and receiving operator role; actual appointment and authority remain pending.
Configuration: Agreed availability-critical journeys and dependency boundary; routes and probe mix pending C08. Data volume: Not a throughput target; use the agreed release dataset and dependencies. Network: Monitoring locations and reachability checks pending C08. Window: Calendar month of agreed service minutes is the existing proposal.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: The service shall achieve at least 99 percent availability. This is the TOR minimum. Proposed measurement is a calendar month of agreed service minutes, including planned maintenance until an exclusion policy is approved.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR01 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Successful service minutes / agreed service minutes ×100; retain monitoring and incident evidence.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Proposed measurement is a calendar month of agreed service minutes, including planned maintenance until an exclusion policy is approved. Pass/fail rule: At least 99 percent after the service boundary and measurement rules are approved. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR02-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client performance owner and receiving operator role; actual appointment and authority remain pending.
Configuration: Existing proposal: 100 concurrent authenticated users; exact bounded read mix, warm-up, cache and think time pending C08. Data volume: Use the NFR04 proposed scale only after dataset mix and distributions are agreed. Network: Measure service duration separately from client/network elapsed time. Window: Steady-state run and warm-up duration pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed target: 100 concurrent authenticated users; standard bounded API reads p95 at most 750 ms and p99 at most 1.5 seconds; error rate below 0.5 percent.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR02 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Instrument bounded service reads; report p95, p99, count, errors, workload and environment.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Proposed target: 100 concurrent authenticated users. Pass/fail rule: Existing proposals: p95≤750 ms, p99≤1.5 s and error rate<0.5 percent at the agreed workload. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR02-C02-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client performance owner and receiving operator role; actual appointment and authority remain pending.
Configuration: Existing proposal: 100 concurrent authenticated users; exact bounded read mix, warm-up, cache and think time pending C08. Data volume: Use the NFR04 proposed scale only after dataset mix and distributions are agreed. Network: Measure service duration separately from client/network elapsed time. Window: Steady-state run and warm-up duration pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed target: 100 concurrent authenticated users; standard bounded API reads p95 at most 750 ms and p99 at most 1.5 seconds; error rate below 0.5 percent.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR02 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Instrument bounded service reads; report p95, p99, count, errors, workload and environment.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: standard bounded API reads p95 at most 750 ms and p99 at most 1.5 seconds. Pass/fail rule: Existing proposals: p95≤750 ms, p99≤1.5 s and error rate<0.5 percent at the agreed workload. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR02-C03-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client performance owner and receiving operator role; actual appointment and authority remain pending.
Configuration: Existing proposal: 100 concurrent authenticated users; exact bounded read mix, warm-up, cache and think time pending C08. Data volume: Use the NFR04 proposed scale only after dataset mix and distributions are agreed. Network: Measure service duration separately from client/network elapsed time. Window: Steady-state run and warm-up duration pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed target: 100 concurrent authenticated users; standard bounded API reads p95 at most 750 ms and p99 at most 1.5 seconds; error rate below 0.5 percent.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR02 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Instrument bounded service reads; report p95, p99, count, errors, workload and environment.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: error rate below 0.5 percent. Pass/fail rule: Existing proposals: p95≤750 ms, p99≤1.5 s and error rate<0.5 percent at the agreed workload. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR03-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client GIS owner and performance specialist role; actual appointment and authority remain pending.
Configuration: Bounded spatial query types, geometry complexity, extent, coordinate system and cache state pending C03/C08/E01. Data volume: Declare geometry count and complexity; do not infer them from the total feature count. Network: Record service query duration separately from map transfer and render time. Window: Repeatable warm/cold query windows pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed target: bounded spatial queries p95 at most 2 seconds and p99 at most 4 seconds.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR03 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Measure the agreed spatial-query set and record all input geometry and environment versions.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Proposed target: bounded spatial queries p95 at most 2 seconds and p99 at most 4 seconds. Pass/fail rule: Existing proposals: p95≤2 s and p99≤4 s for the approved bounded query profile. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR04-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client data custodians and receiving operator role; actual appointment and authority remain pending.
Configuration: Existing proposal: 250 organisations and one million vector features; twice the interactive load for controlled saturation. Data volume: Feature types, sizes, document volume, growth, retention and distributions pending C08. Network: Approved network and hosting profile pending C07/C08. Window: Capacity and saturation test duration pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed sizing: 250 organisations and one million vector features at the agreed workload. Test twice the interactive load for controlled saturation.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR04 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Load the approved scale; exercise read/write/spatial mixes and controlled saturation; observe resource growth and integrity.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Proposed sizing: 250 organisations and one million vector features at the agreed workload. Pass/fail rule: Serve the agreed profile within referenced budgets; reject or queue excess work without corruption, leakage or unbounded memory. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR04-C02-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client data custodians and receiving operator role; actual appointment and authority remain pending.
Configuration: Existing proposal: 250 organisations and one million vector features; twice the interactive load for controlled saturation. Data volume: Feature types, sizes, document volume, growth, retention and distributions pending C08. Network: Approved network and hosting profile pending C07/C08. Window: Capacity and saturation test duration pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed sizing: 250 organisations and one million vector features at the agreed workload. Test twice the interactive load for controlled saturation.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR04 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Load the approved scale; exercise read/write/spatial mixes and controlled saturation; observe resource growth and integrity.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Test twice the interactive load for controlled saturation. Pass/fail rule: Serve the agreed profile within referenced budgets; reject or queue excess work without corruption, leakage or unbounded memory. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR05-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client field-access owner and representative users role; actual appointment and authority remain pending.
Configuration: Core sign-in, list, detail, form and retry journeys on the agreed responsive interface; no extra phone mock screens. Data volume: Essential initial transfer proposal≤1.5 MiB compressed; route/asset boundary pending C08. Network: Existing proposal: 1.5 Mbps down,750 Kbps up,300 ms round trip,1 percent packet loss. Window: Per-journey start/end and cold/warm cache states pending C06/C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed profile: 1.5 Mbps down, 750 Kbps up, 300 ms round trip and 1 percent packet loss. Essential initial transfer at most 1.5 MiB compressed. The system shall support mobile-compatible use of the agreed core journeys on client-agreed devices.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR05 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Throttle the approved profile; complete each core journey, measure transfer/elapsed time and inspect navigation/errors/retry.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Proposed profile: 1.5 Mbps down, 750 Kbps up, 300 ms round trip and 1 percent packet loss. Pass/fail rule: All agreed core journeys remain usable on the accepted matrix; meet the existing transfer budget once boundary is approved. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR05-C02-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client field-access owner and representative users role; actual appointment and authority remain pending.
Configuration: Core sign-in, list, detail, form and retry journeys on the agreed responsive interface; no extra phone mock screens. Data volume: Essential initial transfer proposal≤1.5 MiB compressed; route/asset boundary pending C08. Network: Existing proposal: 1.5 Mbps down,750 Kbps up,300 ms round trip,1 percent packet loss. Window: Per-journey start/end and cold/warm cache states pending C06/C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed profile: 1.5 Mbps down, 750 Kbps up, 300 ms round trip and 1 percent packet loss. Essential initial transfer at most 1.5 MiB compressed. The system shall support mobile-compatible use of the agreed core journeys on client-agreed devices.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR05 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Throttle the approved profile; complete each core journey, measure transfer/elapsed time and inspect navigation/errors/retry.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Essential initial transfer at most 1.5 MiB compressed. Pass/fail rule: All agreed core journeys remain usable on the accepted matrix; meet the existing transfer budget once boundary is approved. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR05-C03-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client field-access owner and representative users role; actual appointment and authority remain pending.
Configuration: Core sign-in, list, detail, form and retry journeys on the agreed responsive interface; no extra phone mock screens. Data volume: Essential initial transfer proposal≤1.5 MiB compressed; route/asset boundary pending C08. Network: Existing proposal: 1.5 Mbps down,750 Kbps up,300 ms round trip,1 percent packet loss. Window: Per-journey start/end and cold/warm cache states pending C06/C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed profile: 1.5 Mbps down, 750 Kbps up, 300 ms round trip and 1 percent packet loss. Essential initial transfer at most 1.5 MiB compressed. The system shall support mobile-compatible use of the agreed core journeys on client-agreed devices.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR05 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Throttle the approved profile; complete each core journey, measure transfer/elapsed time and inspect navigation/errors/retry.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: The system shall support mobile-compatible use of the agreed core journeys on client-agreed devices. Pass/fail rule: All agreed core journeys remain usable on the accepted matrix; meet the existing transfer budget once boundary is approved. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR06-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client accessibility owner and appointed language reviewers role; actual appointment and authority remain pending.
Configuration: Agreed priority journeys and public/authenticated roles; screen-reader and keyboard manual checks. Data volume: Representative forms/tables/errors in each agreed language; content set pending C06. Network: Use the agreed core profile where network affects task completion. Window: Release and changed-journey checks; periodic review cadence pending C06.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed web target is WCAG 2.2 AA. Provide keyboard operation, visible focus, labelled controls, readable error messages, text alternatives, accessible tables and text scaling. English, Sinhala and Tamil coverage requires client agreement.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR06 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Manual and suitable automated checks against the proposed accessibility criteria, with language/domain review.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Proposed web target is WCAG 2.2 AA. Pass/fail rule: Existing proposal: WCAG2.2AA for agreed web scope; keyboard/focus/labels/errors/alternatives/tables/scaling pass; translations accepted. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR06-C02-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client accessibility owner and appointed language reviewers role; actual appointment and authority remain pending.
Configuration: Agreed priority journeys and public/authenticated roles; screen-reader and keyboard manual checks. Data volume: Representative forms/tables/errors in each agreed language; content set pending C06. Network: Use the agreed core profile where network affects task completion. Window: Release and changed-journey checks; periodic review cadence pending C06.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed web target is WCAG 2.2 AA. Provide keyboard operation, visible focus, labelled controls, readable error messages, text alternatives, accessible tables and text scaling. English, Sinhala and Tamil coverage requires client agreement.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR06 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Manual and suitable automated checks against the proposed accessibility criteria, with language/domain review.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Provide keyboard operation, visible focus, labelled controls, readable error messages, text alternatives, accessible tables and text scaling. Pass/fail rule: Existing proposal: WCAG2.2AA for agreed web scope; keyboard/focus/labels/errors/alternatives/tables/scaling pass; translations accepted. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR06-C03-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client accessibility owner and appointed language reviewers role; actual appointment and authority remain pending.
Configuration: Agreed priority journeys and public/authenticated roles; screen-reader and keyboard manual checks. Data volume: Representative forms/tables/errors in each agreed language; content set pending C06. Network: Use the agreed core profile where network affects task completion. Window: Release and changed-journey checks; periodic review cadence pending C06.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed web target is WCAG 2.2 AA. Provide keyboard operation, visible focus, labelled controls, readable error messages, text alternatives, accessible tables and text scaling. English, Sinhala and Tamil coverage requires client agreement.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR06 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Manual and suitable automated checks against the proposed accessibility criteria, with language/domain review.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: English, Sinhala and Tamil coverage requires client agreement. Pass/fail rule: Existing proposal: WCAG2.2AA for agreed web scope; keyboard/focus/labels/errors/alternatives/tables/scaling pass; translations accepted. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR07-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Appointed security specialist and client authority role; actual appointment and authority remain pending.
Configuration: Threat model and agreed verification control set across sessions, inputs, files, exports, transport and secrets. Data volume: Synthetic normal, invalid and malicious test payloads within an authorised isolated scope. Network: Approved isolated boundaries and origins; no real-system penetration or provider writes. Window: Release/changed-control scope and security test window pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Use threat modelling and an agreed OWASP ASVS control set, proposed Level 2. Protect sessions, inputs, files, exports, transport and secrets.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR07 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Review threat model and execute the agreed security verification cases; proposed control level remains unapproved.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Use threat modelling and an agreed OWASP ASVS control set, proposed Level 2. Pass/fail rule: No unresolved critical/high security finding at release; other findings have disposition and owner. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence; permitted export
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR07-C02-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Appointed security specialist and client authority role; actual appointment and authority remain pending.
Configuration: Threat model and agreed verification control set across sessions, inputs, files, exports, transport and secrets. Data volume: Synthetic normal, invalid and malicious test payloads within an authorised isolated scope. Network: Approved isolated boundaries and origins; no real-system penetration or provider writes. Window: Release/changed-control scope and security test window pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Use threat modelling and an agreed OWASP ASVS control set, proposed Level 2. Protect sessions, inputs, files, exports, transport and secrets.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR07 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Review threat model and execute the agreed security verification cases; proposed control level remains unapproved.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Protect sessions, inputs, files, exports, transport and secrets. Pass/fail rule: No unresolved critical/high security finding at release; other findings have disposition and owner. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence; permitted export
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR08-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Institution data owners and qualified privacy reviewer role; actual appointment and authority remain pending.
Configuration: List,detail,count,map,preview,export,originals,results and backups across denied scopes. Data volume: Synthetic personal/sensitive records and permitted summaries; exact retention periods pending C05. Network: Approved processing and disclosure boundaries, residency and transfers pending C05/C07. Window: Before release and each policy/source/classification change; retention schedule pending C05.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Collect only information needed for an approved purpose. Apply classification, disclosure limits, retention and rights handling to originals, results, exports and backups.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR08 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Trace purpose/classification/rights/retention through each copy; execute scope-denial and diagnostic-redaction tests.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Collect only information needed for an approved purpose. Pass/fail rule: Collect only approved-purpose data; all denied outputs and diagnostics reveal no restricted content or secrets. Operational execution remains future and requires authorised evidence.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR08-C02-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Institution data owners and qualified privacy reviewer role; actual appointment and authority remain pending.
Configuration: List,detail,count,map,preview,export,originals,results and backups across denied scopes. Data volume: Synthetic personal/sensitive records and permitted summaries; exact retention periods pending C05. Network: Approved processing and disclosure boundaries, residency and transfers pending C05/C07. Window: Before release and each policy/source/classification change; retention schedule pending C05.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Collect only information needed for an approved purpose. Apply classification, disclosure limits, retention and rights handling to originals, results, exports and backups.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR08 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Trace purpose/classification/rights/retention through each copy; execute scope-denial and diagnostic-redaction tests.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Apply classification, disclosure limits, retention and rights handling to originals, results, exports and backups. Pass/fail rule: Collect only approved-purpose data; all denied outputs and diagnostics reveal no restricted content or secrets. Operational execution remains future and requires authorised evidence.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR09-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Receiving operator and client recovery authority role; actual appointment and authority remain pending.
Configuration: Coordinated relational/geospatial records, protected files, configuration and keys; usable identity/access checks after restore. Data volume: Approved representative release dataset and file set; exact recovery data scale pending C08. Network: Isolated recovery environment and approved backup/restore transfer boundary. Window: Failure declaration to usable recovered service; objective boundary pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed recovery point objective is 24 hours and recovery time objective is 8 hours. Include database, protected files, configuration, keys and spatial resources.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR09 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Restore in isolation; reconcile committed records/files/configuration and verify permitted sign-in/access.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Proposed recovery point objective is 24 hours and recovery time objective is 8 hours. Pass/fail rule: Existing proposals: recovery point≤24 h and recovery time≤8 h, subject to approved boundary and dataset. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR09-C02-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Receiving operator and client recovery authority role; actual appointment and authority remain pending.
Configuration: Coordinated relational/geospatial records, protected files, configuration and keys; usable identity/access checks after restore. Data volume: Approved representative release dataset and file set; exact recovery data scale pending C08. Network: Isolated recovery environment and approved backup/restore transfer boundary. Window: Failure declaration to usable recovered service; objective boundary pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Proposed recovery point objective is 24 hours and recovery time objective is 8 hours. Include database, protected files, configuration, keys and spatial resources.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR09 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Restore in isolation; reconcile committed records/files/configuration and verify permitted sign-in/access.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Include database, protected files, configuration, keys and spatial resources. Pass/fail rule: Existing proposals: recovery point≤24 h and recovery time≤8 h, subject to approved boundary and dataset. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR10-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Solution and data-integrity reviewers role; actual appointment and authority remain pending.
Configuration: Commands,expected versions,retries,business change plus delivery request,workers and provider outages. Data volume: Synthetic duplicate/lost-response/stale-edit/crash/cancellation combinations; scale pending C08. Network: Inject connection loss/provider failure only in isolation. Window: At each transaction/retry boundary and after restart; duration pending accepted retry policy.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Commands shall use expected versions and safe retry references. Save a business change and its delivery request reliably together.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR10 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Fault injection and concurrency tests reconcile records,versions,retry IDs and delivery requests.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Commands shall use expected versions and safe retry references. Pass/fail rule: No duplicate or partial committed business outcome; safe conflicts and original evidence retained. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR10-C02-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Solution and data-integrity reviewers role; actual appointment and authority remain pending.
Configuration: Commands,expected versions,retries,business change plus delivery request,workers and provider outages. Data volume: Synthetic duplicate/lost-response/stale-edit/crash/cancellation combinations; scale pending C08. Network: Inject connection loss/provider failure only in isolation. Window: At each transaction/retry boundary and after restart; duration pending accepted retry policy.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Commands shall use expected versions and safe retry references. Save a business change and its delivery request reliably together.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR10 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Fault injection and concurrency tests reconcile records,versions,retry IDs and delivery requests.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Save a business change and its delivery request reliably together. Pass/fail rule: No duplicate or partial committed business outcome; safe conflicts and original evidence retained. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR11-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Provider technical owners and receiving integration owner role; actual appointment and authority remain pending.
Configuration: Versioned service/data contracts,geospatial formats,units,coordinate systems,pagination and source failure. Data volume: Approved bounded message/file sizes and representative mappings; limits pending C04/C08. Network: Only approved endpoints/origins when authorised; this prototype uses local replay. Window: Contract edition change and scheduled compatibility tests; cadence pending provider agreement.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Publish versioned API and data contracts. Declare supported geospatial protocols, encodings, units, coordinate systems and export formats.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR11 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Validate published schemas/errors,unsupported versions,mapping changes,paging,retry and source-failure responses.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Publish versioned API and data contracts. Pass/fail rule: Only declared versions/formats accepted; failures are safe and reproducible; source/mapping identity preserved. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence; permitted export
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR11-C02-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Provider technical owners and receiving integration owner role; actual appointment and authority remain pending.
Configuration: Versioned service/data contracts,geospatial formats,units,coordinate systems,pagination and source failure. Data volume: Approved bounded message/file sizes and representative mappings; limits pending C04/C08. Network: Only approved endpoints/origins when authorised; this prototype uses local replay. Window: Contract edition change and scheduled compatibility tests; cadence pending provider agreement.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Publish versioned API and data contracts. Declare supported geospatial protocols, encodings, units, coordinate systems and export formats.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR11 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Validate published schemas/errors,unsupported versions,mapping changes,paging,retry and source-failure responses.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Declare supported geospatial protocols, encodings, units, coordinate systems and export formats. Pass/fail rule: Only declared versions/formats accepted; failures are safe and reproducible; source/mapping identity preserved. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence; permitted export
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR12-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client receiving institution and appointed maintenance team role; actual appointment and authority remain pending.
Configuration: Reproducible build,configuration,migration,operation contracts,restore and complete export. Data volume: Approved source/configuration/data/file export scope; exact artefact set pending C07. Network: Isolated installation with approved dependency sources; no connection to the real system. Window: Each release/handover and supported dependency change; support cadence pending C07.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Keep business definitions configurable, modules separated and dependencies supported. Supply reproducible builds, migrations, operation contracts and complete export.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR12 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Receiving team follows supplied instructions to install an isolated copy and reproduce build/restore/migration/export.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Keep business definitions configurable, modules separated and dependencies supported. Pass/fail rule: Business definitions remain configurable; modules remain separate; supported dependencies and complete portable export are demonstrated. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence; permitted export
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR12-C02-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client receiving institution and appointed maintenance team role; actual appointment and authority remain pending.
Configuration: Reproducible build,configuration,migration,operation contracts,restore and complete export. Data volume: Approved source/configuration/data/file export scope; exact artefact set pending C07. Network: Isolated installation with approved dependency sources; no connection to the real system. Window: Each release/handover and supported dependency change; support cadence pending C07.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Keep business definitions configurable, modules separated and dependencies supported. Supply reproducible builds, migrations, operation contracts and complete export.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR12 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Receiving team follows supplied instructions to install an isolated copy and reproduce build/restore/migration/export.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Supply reproducible builds, migrations, operation contracts and complete export. Pass/fail rule: Business definitions remain configurable; modules remain separate; supported dependencies and complete portable export are demonstrated. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence; permitted export
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR13-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Security and operations reviewers role; actual appointment and authority remain pending.
Configuration: Protected business audit separate from redacted diagnostics; request/action/source/review chains and denied access. Data volume: Representative normal/denied/publication/error events; audit retention and capacity pending C05/C08. Network: Approved audit/alert storage and delivery boundary; no secrets/private source content in diagnostics. Window: Request sample window and event-query timing pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Retain protected business audit separately from redacted diagnostics. Proposed correlation target is at least 99 percent of API requests; significant events queryable within five minutes.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR13 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Reconcile eligible requests to correlation records; time significant-event queryability and trace source/review/actor.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Retain protected business audit separately from redacted diagnostics. Pass/fail rule: Existing proposals:≥99 percent request correlation and significant events queryable within5min; audit/redaction checks pass. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR13-C02-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Security and operations reviewers role; actual appointment and authority remain pending.
Configuration: Protected business audit separate from redacted diagnostics; request/action/source/review chains and denied access. Data volume: Representative normal/denied/publication/error events; audit retention and capacity pending C05/C08. Network: Approved audit/alert storage and delivery boundary; no secrets/private source content in diagnostics. Window: Request sample window and event-query timing pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Retain protected business audit separately from redacted diagnostics. Proposed correlation target is at least 99 percent of API requests; significant events queryable within five minutes.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR13 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Reconcile eligible requests to correlation records; time significant-event queryability and trace source/review/actor.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Proposed correlation target is at least 99 percent of API requests. Pass/fail rule: Existing proposals:≥99 percent request correlation and significant events queryable within5min; audit/redaction checks pass. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR13-C03-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Security and operations reviewers role; actual appointment and authority remain pending.
Configuration: Protected business audit separate from redacted diagnostics; request/action/source/review chains and denied access. Data volume: Representative normal/denied/publication/error events; audit retention and capacity pending C05/C08. Network: Approved audit/alert storage and delivery boundary; no secrets/private source content in diagnostics. Window: Request sample window and event-query timing pending C08.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Retain protected business audit separately from redacted diagnostics. Proposed correlation target is at least 99 percent of API requests; significant events queryable within five minutes.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR13 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Reconcile eligible requests to correlation records; time significant-event queryability and trace source/review/actor.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: significant events queryable within five minutes. Pass/fail rule: Existing proposals:≥99 percent request correlation and significant events queryable within5min; audit/redaction checks pass. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
NFR14-C01-A01 · focused acceptance scenario
Actor and scope: Synthetic test operator under the proposed Client service owner and receiving operator role; actual appointment and authority remain pending.
Configuration: Service/support levels,escalation,funding,renewal,patching,continuity and knowledge transfer. Data volume: Accepted service/module/dependency inventory,users and source commitments; scope pending C01/C07. Network: Hosting/support/provider access and continuity routes pending C07. Window: Before operational acceptance; review/renewal/escalation schedules pending contract.
Input fixture: FIX-OPERATIONS isolated release and synthetic data/file/request fixtures. Existing proposal: Name the service owner, support levels, escalation, funding, renewal obligations and patch responsibility before operational acceptance.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Freeze the NFR14 configuration values through the existing decision references before execution.; Prepare FIX-OPERATIONS in an isolated environment with the accepted workload/data/device/network profile.; Measure or exercise: Review the costed support plan and dependency inventory; exercise incident routing,continuity and receiving-team knowledge transfer.; Apply the declared exclusions explicitly, retain raw observations and compare with the rule. Record unknown/missing configuration as blocked, never as pass.
Expected result: Name the service owner, support levels, escalation, funding, renewal obligations and patch responsibility before operational acceptance. Pass/fail rule: Named authority accepts a funded support/renewal/patch plan and completed continuity/knowledge-transfer evidence. Operational execution remains future and requires authorised evidence.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases:
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR149-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: SHARED must protect private people and sensitive locations from disclosure through search, counts and exports. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR149-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: If an action creates a notification, save the action and delivery request reliably together. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR149-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Retry delivery without duplicating the message. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR151-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: SHARED must separate development, test, staging and production configuration and inject secrets through protected settings. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence; permitted export
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR151-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Do not publish credentials or private data in code, documents, logs or exports. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence; permitted export
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR152-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: SHARED must monitor service availability, failures and background processing. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR152-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Retain safe diagnostic details and a request reference so an authorised operator can investigate an error. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR152-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Health responses and logs must not expose credentials, personal records or original source content. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-VERSION-STALE; SC-VERSION-CHANGE
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR153-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: SHARED must support reviewed procedures for deployment, migration, rollback or forward repair, credential rotation, incidents and continuity. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR153-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Do not upgrade the database at application startup. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-VERSION-STALE; SC-VERSION-CHANGE; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR154-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: SHARED must back up the database and protected files under agreed security and retention rules. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR154-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Confirm recovery targets through an authorized restore exercise, not backup creation alone. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases: SC-AUTH-ALLOW; SC-AUTH-DENY; SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-INTERFACE-BAD
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR150-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: SHARED must keep business settings editable and dated. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR150-C02-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Register proposed products before claiming delivery. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR150-C03-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: Link requirements to design, work, implementation, tests and evidence, with controlled change history. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-VERSION-STALE; SC-VERSION-CHANGE; SC-RETRY-SAME; SC-RETRY-CRASH
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR150-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR150.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
FR156-C01-A01 · focused acceptance scenario
Actor and scope: SYN-USER-PREP in the proposed role: PMU product owner and proposed technical/service owners; named acceptance authority pending. Use SYN-USER-REVIEW for independent review and SYN-USER-DENIED for denial. Actual authority remains pending.
Configuration: Use FIX-OPERATIONS with explicit versions and accepted parameters: P_SELECTED_SERVICE_BOUNDARY, P_CONTROLLED_OPERATION_CATALOGUE, P_LOG_REDACTION_RETENTION, P_RECOVERY_TARGETS, P_SUPPORT_OWNER_FUNDING, P_OPERATOR_ACCEPTANCE. Parameter values remain pending until the responsible authority freezes them.
Input fixture: FIX-OPERATIONS: Configuration, audit, reliable operations and receiving handover. Use owner=SYN-ORG-A, otherOwner=SYN-ORG-B, preparer=SYN-USER-PREP. Full shared fixture values are linked once in the annex.
Preconditions: Agreed release/option scope and acceptance configuration; isolated environment; named preparer/reviewer roles where required; no real-system access.
Steps: Prepare the isolated SYN-RELEASE-A configuration, operation catalogue, records/files and receiving copy.; Run the focused configured operation, audit/recovery/change/handover procedure with synthetic evidence.; Reconcile permissions, immutable history, diagnostic redaction and receiving responsibility; no deployment or acceptance is inferred.
Expected result: SHARED must track unfinished software separately from missing data, expert decisions and governance approval. Compare the exact named value/state/link in FIX-OPERATIONS under its accepted policy parameters. Preserve the full parent requirement conditions.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Not applicable unless the linked operation uses protected resources
Shared cases: SC-DATA-VALID; SC-DATA-INVALID; SC-DATA-MISSING; SC-DATA-ZERO-FALSE; SC-DATA-BOUNDS; SC-STATE-VALID; SC-STATE-INVALID
Evidence type: Future service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; this row defines a test, not a result.
FR156-D01 · prototype-design
Actor and scope: Reviewer in an isolated prototype context; role controls are a preview, not authenticated authority.
Configuration: Candidate Version 1.6; existing route https://sharedproto.wkslabs.com/reviews/dashboard-portfolio-20261027/#data-entry-DP08; fresh browser state; all external writes blocked.
Input fixture: Synthetic local fixture only; no real records, approvals or provider actions.
Preconditions: Candidate build and relevant prototype scenario are available. The real-system host is blocked.
Steps: Open the retained prototype entry.; Check the fields, actions, labels, sample status and limitations against FR156.; Exercise the relevant local mock scenario and record the exact supported clauses and any unsupported ones.
Expected result: The mock accurately demonstrates its supported interaction and clearly marks pending or future behavior. It does not claim operational proof.
Output paths: configured operation/receipt; audit/operational evidence
Permission dimensions: Prototype role/scope preview only
Shared cases:
Evidence type: Executable prototype design check
Result status: Not executed — candidate check defined
Execution evidence: None until a fresh candidate receipt names this case and supported clauses.
SC-AUTH-ALLOW · positive
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: All nine required scope dimensions permit the actor; exercise list/search, detail, count, map, file/preview and export/report.
Input fixture: FIX-SCOPE; All nine required scope dimensions permit the actor; exercise list/search, detail, count, map, file/preview and export/report.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Create FIX-SCOPE allowed/sibling records and the explicit nine-dimension grant.; For each of action,organization,stakeholder,domain,project,geography,record,classification and workflow state, change only that dimension to denied.; For each variation read list/search,detail,count,map,file/preview and export/report: all54 dimension/path combinations.; Restore the single grant and repeat allowed retrieval; retain a per-combination result, not just one overall flag.
Expected result: Only permitted information is returned, with the same scope on every output path.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-AUTH-DENY · unauthorized-access
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Change one of action, organization, stakeholder, domain, project, geography, record, classification or workflow state to denied. Repeat all six output paths for every dimension.
Input fixture: FIX-SCOPE; Change one of action, organization, stakeholder, domain, project, geography, record, classification or workflow state to denied. Repeat all six output paths for every dimension.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Create FIX-SCOPE allowed/sibling records and the explicit nine-dimension grant.; For each of action,organization,stakeholder,domain,project,geography,record,classification and workflow state, change only that dimension to denied.; For each variation read list/search,detail,count,map,file/preview and export/report: all54 dimension/path combinations.; Restore the single grant and repeat allowed retrieval; retain a per-combination result, not just one overall flag.
Expected result: Every denied combination yields no protected content, descriptive metadata, counts, files or export rows.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: action; organization; stakeholder; domain; project; geography; record; classification; workflow state
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-DATA-VALID · positive
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Exact definition and mapping versions; valid numeric, text, Boolean and date examples where each type is supported.
Input fixture: FIX-DEFINITION; Exact definition and mapping versions; valid numeric, text, Boolean and date examples where each type is supported.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: Preserve the supplied value, type, unit, source and version.
Output paths: All output paths bound by each linked clause
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-DATA-INVALID · invalid-input
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Wrong type, unknown property or disallowed vocabulary for the accepted definition version.
Input fixture: FIX-DEFINITION; Wrong type, unknown property or disallowed vocabulary for the accepted definition version.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: Reject the field with a clear correction; do not coerce it into a plausible value.
Output paths: All output paths bound by each linked clause
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-DATA-MISSING · missing-data
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Omit a required value; use an explicit missing reason for a permitted optional value.
Input fixture: FIX-DEFINITION; Omit a required value; use an explicit missing reason for a permitted optional value.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: Block required omissions. Preserve permitted missing reasons without inventing zero or an observation.
Output paths: All output paths bound by each linked clause
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-DATA-ZERO-FALSE · boundary
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: On suitable typed fields, submit numeric zero, Boolean false, empty text, omitted value and not-applicable separately.
Input fixture: FIX-DEFINITION; On suitable typed fields, submit numeric zero, Boolean false, empty text, omitted value and not-applicable separately.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: Keep all five meanings distinct; reject an unsupported meaning instead of coercing it.
Output paths: All output paths bound by each linked clause
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-DATA-BOUNDS · boundary
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: For an accepted bound L/U, test L, U and values immediately outside each bound. If no bounds apply, record a reasoned N/A.
Input fixture: FIX-DEFINITION; For an accepted bound L/U, test L, U and values immediately outside each bound. If no bounds apply, record a reasoned N/A.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Create SYN-DEF-A@v1 and SYN-MAP-A@v1 as synthetic definitions with explicit type/unit/missing policies.; Submit values through the configured form and mapping, then revise the definition to v2.; Read v1 submissions with their original definition; test zero, false, empty, missing and not-applicable separately.
Expected result: Apply the published inclusive/exclusive limits exactly; never invent a scientific threshold.
Output paths: All output paths bound by each linked clause
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-VERSION-STALE · concurrency
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Two actors read revision v1; actor A saves v2; actor B attempts the v1 command.
Input fixture: FIX-PROJECT; Two actors read revision v1; actor A saves v2; actor B attempts the v1 command.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Reject or explicitly resolve the stale operation; preserve v1/v2 and no partial or silent overwrite.
Output paths: All output paths bound by each linked clause
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-VERSION-CHANGE · failure
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Change the relevant source, mapping, definition or approval version after preview and before commit/read.
Input fixture: FIX-PROJECT; Change the relevant source, mapping, definition or approval version after preview and before commit/read.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Recheck the exact bound version and rights. Invalidate stale approval/results only according to their dependency rules.
Output paths: All output paths bound by each linked clause
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-STATE-VALID · positive
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Separate authorised preparer/reviewer with the exact configured transition and required evidence.
Input fixture: FIX-PROJECT; Separate authorised preparer/reviewer with the exact configured transition and required evidence.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Save one valid state transition and its immutable decision evidence.
Output paths: All output paths bound by each linked clause
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-STATE-INVALID · invalid-input
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Wrong actor, self-review where independence is required, omitted evidence or prohibited state transition.
Input fixture: FIX-PROJECT; Wrong actor, self-review where independence is required, omitted evidence or prohibited state transition.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Create or import SYN-PROJECT-A with its legacy ID, explicit applicability and known history only.; Issue a versioned obligation/task, submit evidence, update monitoring and attempt closure with one required check incomplete.; Reconcile original revisions, due/state/evidence and indicator inputs; prohibited acceptance/closure fails atomically.
Expected result: Reject atomically; leave the prior state and evidence unchanged.
Output paths: All output paths bound by each linked clause
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-RETRY-SAME · failure
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Repeat the same retry ID after a lost response; replay an unchanged source message.
Input fixture: FIX-IMPORT; Repeat the same retry ID after a lost response; replay an unchanged source message.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Validate and independently review SYN-BATCH-A with the exact included rows and SYN-IMPORT-CMD-A.; Lose the response after the accepted write, repeat the same retry ID and reconcile the original outcome.; Repeat the same command with changed bytes; interrupt at each write/delivery boundary and restart/cancel the isolated worker.; Confirm one consistent outcome, explicit conflict/failure and immutable original evidence; no duplicate message or partial batch.
Expected result: Return or reuse the original outcome without duplicate business records or delivery requests.
Output paths: All output paths bound by each linked clause
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-RETRY-CRASH · failure
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Interrupt at the write/delivery boundary, cancel bounded work and simulate an unavailable provider.
Input fixture: FIX-IMPORT; Interrupt at the write/delivery boundary, cancel bounded work and simulate an unavailable provider.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Validate and independently review SYN-BATCH-A with the exact included rows and SYN-IMPORT-CMD-A.; Lose the response after the accepted write, repeat the same retry ID and reconcile the original outcome.; Repeat the same command with changed bytes; interrupt at each write/delivery boundary and restart/cancel the isolated worker.; Confirm one consistent outcome, explicit conflict/failure and immutable original evidence; no duplicate message or partial batch.
Expected result: No partial business commit or fabricated success. Preserve original evidence and a safe resumable/rejected status.
Output paths: All output paths bound by each linked clause
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-PUBLIC-ALLOW · positive
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Published public record, allowed audience, required source identity and explicit exact-version rights.
Input fixture: FIX-SOURCE; Published public record, allowed audience, required source identity and explicit exact-version rights.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Publish SYN-OBS-A bound to explicitly allowed SYN-SOURCE-A@v1 and independently eligible citations.; Exercise fresh public list,detail,map,count,cache and export.; Apply the selected withdrawal,expiry,restriction,missing/cyclic reference or exact-version rights variation; repeat every public path.; Verify authorised internal provenance/history persists. Separately allow v1 while v2 exists, then remove only v1 rights and retest.
Expected result: Allow fresh public list, detail, map, count, cache and export only while all dependencies remain eligible.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-PUBLIC-WITHDRAW · unauthorized-access
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: After allowed publication, withdraw, expire, restrict, remove or make cyclic a required source/citation dependency; remove exact-version use rights.
Input fixture: FIX-SOURCE; After allowed publication, withdraw, expire, restrict, remove or make cyclic a required source/citation dependency; remove exact-version use rights.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Publish SYN-OBS-A bound to explicitly allowed SYN-SOURCE-A@v1 and independently eligible citations.; Exercise fresh public list,detail,map,count,cache and export.; Apply the selected withdrawal,expiry,restriction,missing/cyclic reference or exact-version rights variation; repeat every public path.; Verify authorised internal provenance/history persists. Separately allow v1 while v2 exists, then remove only v1 rights and retest.
Expected result: Suppress fresh dependent public output on every path, including cache/count. Preserve permitted internal history. Do not claim recall of downloaded copies.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-PUBLIC-OLDVERSION · boundary
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Publish a newer source version but retain an explicitly permitted older binding; separately remove rights only for the bound version.
Input fixture: FIX-SOURCE; Publish a newer source version but retain an explicitly permitted older binding; separately remove rights only for the bound version.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Publish SYN-OBS-A bound to explicitly allowed SYN-SOURCE-A@v1 and independently eligible citations.; Exercise fresh public list,detail,map,count,cache and export.; Apply the selected withdrawal,expiry,restriction,missing/cyclic reference or exact-version rights variation; repeat every public path.; Verify authorised internal provenance/history persists. Separately allow v1 while v2 exists, then remove only v1 rights and retest.
Expected result: The permitted older version stays eligible; the disallowed exact version is suppressed. Never infer rights from newest-version status.
Output paths: list/search; detail; count; map; file/preview; export/report
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
SC-INTERFACE-BAD · invalid-input
Actor and scope: Synthetic permitted user, denied user and independent reviewer according to the clause bindings; proposed roles only.
Configuration: Exact accepted schema, permission, source, mapping, workflow and method versions from the linked clauses. Parameters: Unsupported contract/version/property, malformed payload, oversized request and unsafe active content as relevant.
Input fixture: FIX-INTERFACE; Unsupported contract/version/property, malformed payload, oversized request and unsafe active content as relevant.
Preconditions: Isolated future service implementation and approved acceptance configuration. Do not connect to real services.
Steps: Expose only the isolated SYN-CONTRACT-v1 operations under the approved test policy.; Send an allowed request, then the focused insecure, disallowed-origin, oversized or unauthorised variation.; Compare safe status/error references and unchanged records; inspect redacted diagnostics for leakage.
Expected result: Return a safe bounded error without secrets or a partial write; do not execute supplied scripts, macros or external entities.
Output paths: All output paths bound by each linked clause
Permission dimensions: Relevant approved resource scope
Shared cases:
Evidence type: Future shared service acceptance
Result status: Not executed — future service acceptance
Execution evidence: None; shared reusable case definition.
Synthetic fixture contracts
These fixtures define test inputs. They are not real accounts, institutional data or approved policy values. Supply temporary secrets only at execution and keep them out of evidence.
FIX-SECURITY · Sign-in, lockout, token/session and privileged factor controls
Values: accounts: SYN-ACCOUNT-A; SYN-ADMIN-A; SYN-ACCESS-REVIEWER-A; SYN-POLICY-ROLE-A; ephemeralSecret: Provide only at execution; never save in the annex or evidence.; session: SYN-SESSION-A; token: Ephemeral redacted token, bound to SYN-ACCOUNT-A; states: active; disabled; revoked
Parameters: P_LOCKOUT_ATTEMPTS; P_LOCKOUT_WINDOW; P_LOCKOUT_RECOVERY; P_TOKEN_EXPIRY; P_MFA_ROLE_SET; P_APPROVED_HASH_POLICY
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-SCOPE · Permission dimensions and output-path consistency
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; allowRule: SYN-GRANT-ALL-A; denyRule: Remove exactly one required permission dimension from SYN-GRANT-ALL-A.; rows: SYN-REC-A matches all permitted scopes; SYN-REC-B belongs to a different owner/domain/project/area and remains restricted.; outputPaths: list/search; detail; count; map; file/preview; export/report
Parameters: P_ACTION; P_CLASSIFICATION; P_WORKFLOW_STATE; P_STAKEHOLDER; P_AUDIENCE; P_CURRENT_POLICY_VERSION
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-SOURCE · Catalogue metadata, exact source versions and allowed uses
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; source: SYN-SOURCE-A; versions: v1; v2; custodian: SYN-ORG-B; licence: SYN-LICENCE-A; cadence: SYN-PERIODIC-A; coverage: SYN-AREA-A, period P0–P1; quality: unreviewed synthetic input; classification: Internal test fixture; distribution: SYN-FILE-A-v1; rights: SYN-USE-GRANT-A explicitly permits the selected v1 use; boundRecord: SYN-OBS-A bound to SYN-SOURCE-A@v1
Parameters: P_ALLOWED_AUDIENCE; P_USE_PURPOSE; P_RIGHTS_EXPIRY; P_ACCEPTED_SOURCE_MAPPING
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-DEFINITION · Typed definitions, source mappings and value meanings
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; definition: SYN-DEF-A@v1; mapping: SYN-MAP-A@v1; numericField: area_ha; booleanField: verified_flag; textField: note; permittedExamples: area_ha: 0; verified_flag: False; note: ; otherMeanings: omitted value; explicit not-applicable with permitted reason; nextVersions: SYN-DEF-A@v2; SYN-MAP-A@v2
Parameters: P_FIELD_TYPE; P_REQUIRED_FIELDS; P_ALLOWED_VOCABULARY; P_LOWER_BOUND_L; P_UPPER_BOUND_U; P_BOUND_INCLUSIVITY; P_MISSING_REASON_POLICY
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-GEOMETRY · Controlled synthetic geometry and geographic validation
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; type: SYN-TYPE-A@v1; source: SYN-SOURCE-A@v1; fixtureOnlyCRS: Declared longitude/latitude interchange coordinates; fixtureOnlyExtent: -1; -1; 1; 1; validPoint: type: Point; coordinates: 0; 0; validPolygon: type: Polygon; coordinates: 0; 0; 0.2; 0; 0.2; 0.2; 0; 0.2; 0; 0; selfIntersectingPolygon: type: Polygon; coordinates: 0; 0; 0.2; 0.2; 0.2; 0; 0; 0.2; 0; 0; unclosedPolygon: type: Polygon; coordinates: 0; 0; 0.2; 0; 0.2; 0.2; 0; 0.2; emptyGeometry: type: Polygon; coordinates: ; invalidGlobalRange: 181; 91; time: T_OBS; relatedObject: SYN-OBJECT-A; duplicateRetryId: SYN-GEO-CMD-A
Parameters: P_ALLOWED_CRS; P_AXIS_ORDER; P_GEOMETRY_ROLE; P_TYPE_GEOMETRIES; P_TOPOLOGY_RULE; P_MAX_VERTICES_V; P_QUERY_LIMIT_Q; P_TIME_RULE; P_REQUIRED_FIELDS; P_ACCEPTED_SOURCE_VERSION
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-REFERENCE · Authoritative choices, language keys and terminology review
Values: referenceVersion: SYN-REF-v1; allowedChoiceIds: SYN-CHOICE-A; SYN-CHOICE-B; injectedChoiceId: SYN-CHOICE-C; languageKeys: en; si; ta; translationKeys: choice.label; form.required; action.save; state.denied; terminologyReview: Pending until an execution fixture supplies a permitted independent reviewer decision.
Parameters: P_AGREED_LANGUAGE_SCOPE; P_APPROVED_TERM_EDITION; P_REQUIRED_RESOURCE_KEYS; P_APPOINTED_REVIEW_AUTHORITY
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-INTERFACE · Transport, origin, header, input and resource checks
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; allowedOrigin: https://allowed.example.test; deniedOrigin: https://denied.example.test; unknownProperty: unsupported_field; invalidScalar: not-a-number; safeErrorReference: SYN-REQUEST-A; supportedContract: SYN-CONTRACT-v1; unsupportedContract: SYN-CONTRACT-unknown
Parameters: P_SECURE_TRANSPORT_POLICY; P_REQUIRED_HEADER_SET_H; P_ALLOWED_ORIGIN_SET; P_RATE_LIMIT_Q; P_RATE_WINDOW_W; P_PAYLOAD_LIMIT; P_ENDPOINT_ACTION; P_RESOURCE_GRANT
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-IMPORT · Structured import, mapping, preview, independent approval and retry
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; original: SYN-IMPORT-A; schema: SYN-SCHEMA-v1; mapping: SYN-MAP-v1; validRow: source_key: SYN-ROW-1; area_ha: 3.5; verified_flag: False; zeroRow: source_key: SYN-ROW-2; area_ha: 0; verified_flag: False; invalidRow: source_key: SYN-ROW-3; area_ha: invalid numeric text; batch: SYN-BATCH-A; retryId: SYN-IMPORT-CMD-A; formats: CSV; XLSX; JSON scalar rows; restricted XML rows
Parameters: P_SUPPORTED_CONTRACT; P_REQUIRED_FIELDS; P_FILE_SIZE_LIMIT; P_INCLUDED_ROW_IDS; P_APPROVAL_VERSION; P_DUPLICATE_POLICY
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-EXTRACTION · Original document, suggestion provenance and human validation
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; original: SYN-DOC-A@v1; passage: Synthetic plot A has a reported area of 3.5 ha.; locator: page 1, passage 1; suggestion: SYN-SUG-A: area_ha=3.5; uncertainty: SYN-UNCONFIRMED; mapping: SYN-MAP-v1
Parameters: P_PROCESSOR_PERMISSION; P_CLEAN_SCAN_RECEIPT; P_SUPPORTED_DESTINATION; P_CURRENT_DEFINITION_VERSION; P_INDEPENDENT_REVIEWER
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-FEED · Approved mapping, replayed messages and source-event identity
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; feed: SYN-FEED-A; messageId: SYN-MSG-A; observed: T0; received: T1; mapping: SYN-FEED-MAP-v1; value: 0; origin: synthetic replay; changedRevision: SYN-MSG-A correction v2
Parameters: P_ENABLED_FEED; P_APPROVED_ADAPTER_CONTRACT; P_EXACT_SOURCE_VERSION; P_FIELD_UNIT_MAPPING; P_GATEWAY_PERMISSION; P_ALL_OR_NONE_POLICY
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-CLAIMS · Preserved source claims and reviewed correction choices
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; claimA: SYN-CLAIM-A: 10 ha at P0 from SYN-SOURCE-A@v1; claimB: SYN-CLAIM-B: 8 ha at P0 from SYN-SOURCE-B@v1; choice: SYN-CHOICE-REVIEW-A; correction: SYN-CLAIM-A@v2
Parameters: P_COMPARABLE_UNIT_PLACE_PERIOD; P_REVIEW_AUTHORITY; P_APPROVED_PLAUSIBILITY_RULE
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-SPATIAL · Layer lineage, bounded vector/raster analysis and missing cells
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; layer: SYN-LAYER-A@v1; source: SYN-SOURCE-A@v1; rasterCells: 1; 2; None; 4; geometryFixture: FIX-GEOMETRY; result: SYN-SPATIAL-RUN-A; origin: explicit synthetic demonstration
Parameters: P_CRS_RESOLUTION_EXTENT; P_CLASS_MEANING; P_NODATA; P_CELL_ALIGNMENT; P_METHOD_UNITS; P_VOLUME_LIMIT; P_DISCLOSURE_POLICY
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-CLIMATE · Observed climate series, forecast validity and no invented warnings
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; series: SYN-RAIN-A; observations: P0: known rainfall 0 mm; P1: missing observation, no inferred zero; forecast: SYN-FORECAST-A with issue T0 and validity T1–T2; cropRecord: SYN-PLOT-CROP-A with a declared reporting period; origin: synthetic reference series
Parameters: P_PRODUCT_VARIABLE_UNIT; P_ACCEPTED_ALLOCATION_METHOD; P_SOURCE_REFRESH_POLICY; P_WARNING_AUTHORITY
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-MARKET · Compatible production, demand, margin and payment evidence
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; product: SYN-PRODUCT-A; harvest: SYN-HARVEST-A: 10 kg in P0; demand: SYN-DEMAND-A: 8 kg in P0; differentPeriod: SYN-DEMAND-B: 8 kg in P1; cost: Known synthetic variable cost; separate unknown-cost variation; paymentEvidence: SYN-PAY-EVIDENCE-A, recorded evidence only; pesAgreement: SYN-PES-A; no approved operational rate supplied
Parameters: P_PRODUCT_UNIT_PERIOD_CURRENCY; P_APPROVED_FORMULA_VERSION; P_ELIGIBILITY_RATE_AUTHORITY; P_PAYMENT_STAGE_VOCABULARY
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-REPORT · Explicit report grain, joins, missing rows and reproducible export
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; sourceA: key A,area_ha=3.5; key B,area_ha=0; sourceB: key A,review=synthetic reviewed; key C,review=unknown; duplicateVariation: Add a second sourceB row with key A.; report: SYN-REPORT-A@v1; run: SYN-RUN-A; grain: one output row per key at period P0
Parameters: P_ALLOWED_FIELDS_FILTERS_AGGREGATIONS; P_EXACT_INPUT_VERSIONS; P_APPROVED_JOIN_TYPE; P_MISSING_ROW_POLICY; P_EXPORT_PUBLICATION_POLICY
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-DECISION · Evidence-linked option comparison, authority and action follow-up
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; case: SYN-DECISION-A; options: SYN-OPTION-A; SYN-OPTION-B; criterionInputs: Equal compatible synthetic values for both options; separate missing-input variation.; planZero: Plan=0; actual is recorded separately, percentage variance unavailable.; action: SYN-ACTION-A; knowledgeCitation: SYN-KNOWLEDGE-A@v1
Parameters: P_METHOD_VERSION; P_REVIEWED_WEIGHTS_ANCHORS; P_UNIT_PLACE_PERIOD; P_AUTHORITY_INDEPENDENCE; P_ROUTING_POLICY
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-PROJECT · Project revisions, obligations, indicator evidence and closure
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A@v1; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; originalImportedId: SYN-LEGACY-PROJECT-A; obligation: SYN-OBLIGATION-A, occurrence P0; task: SYN-TASK-A; indicator: SYN-INDICATOR-A, baseline unknown, target separate from observations; closure: SYN-CLOSURE-A with one deliberately incomplete required check
Parameters: P_ACCEPTED_COMPONENT_SCOPE; P_FORM_SCHEMA_VERSION; P_DUE_DATE; P_REQUIRED_EVIDENCE; P_ACCEPTED_INDICATOR_METHOD; P_FROZEN_CLOSURE_CHECKS
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-KNOWLEDGE · Protected originals, evidence versions, publication and feedback
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; original: SYN-EVIDENCE-A@v1; replacement: SYN-EVIDENCE-A@v2; safeFile: Synthetic plain-text file with known bytes, type and checksum.; badSignature: Synthetic mismatched type/signature metadata; no executable payload.; citation: SYN-SOURCE-A@v1; feedback: SYN-FEEDBACK-A; grievance: SYN-GRIEVANCE-A, separate protected workflow
Parameters: P_FILE_SIZE_TYPE_POLICY; P_GENUINE_SCAN_RECEIPT; P_PUBLICATION_AUTHORITY; P_RECEIVER_MODERATION_APPEAL; P_RETENTION_POLICY
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-CHANNEL · Responsive core and explicitly conditional additional/offline channel
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; assignment: SYN-FIELD-ASSIGNMENT-A; draft: SYN-DRAFT-A; command: SYN-FIELD-CMD-A; states: pending; sending; received; rejected; conflict; source: SYN-SOURCE-A@v1
Parameters: P_APPROVED_CORE_JOURNEYS; P_DEVICE_LANGUAGE_MATRIX; P_CHANNEL_SELECTION; P_LOCAL_STORAGE_PERMISSION; P_RETENTION_ENCRYPTION_POLICY; P_OFFLINE_SELECTION
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
FIX-OPERATIONS · Configuration, audit, reliable operations and receiving handover
Values: owner: SYN-ORG-A; otherOwner: SYN-ORG-B; preparer: SYN-USER-PREP; reviewer: SYN-USER-REVIEW; deniedUser: SYN-USER-DENIED; domain: SYN-DOMAIN-A; otherDomain: SYN-DOMAIN-B; project: SYN-PROJECT-A; otherProject: SYN-PROJECT-B; area: SYN-AREA-A; otherArea: SYN-AREA-B; record: SYN-REC-A; otherRecord: SYN-REC-B; configuration: SYN-CONFIG-v1; release: SYN-RELEASE-A; request: SYN-REQUEST-A; auditEvent: SYN-AUDIT-A; backupSet: SYN-RECOVERY-A; receivingCopy: Isolated synthetic receiving environment only
Parameters: P_SELECTED_SERVICE_BOUNDARY; P_CONTROLLED_OPERATION_CATALOGUE; P_LOG_REDACTION_RETENTION; P_RECOVERY_TARGETS; P_SUPPORT_OWNER_FUNDING; P_OPERATOR_ACCEPTANCE
Authority: Synthetic test design only. These records, values and policy references are not institutional appointments, live providers, approved scientific parameters or executed acceptance evidence.
NFR conditions
These rows retain the existing numerical proposals. The client and operator must agree the test conditions before operational acceptance. Unknown values stay pending.
NFR01 · Availability
Existing proposal: The service shall achieve at least 99 percent availability. This is the TOR minimum. Proposed measurement is a calendar month of agreed service minutes, including planned maintenance until an exclusion policy is approved.
Source locator: SRS Version 1.5, NFR01, body after heading at paragraph 1324
Proposed owner: Client service owner and receiving operator
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Agreed availability-critical journeys and dependency boundary; routes and probe mix pending C08.
Data volumes: Not a throughput target; use the agreed release dataset and dependencies.
User device browser coverage: Agreed public and authenticated channels; device/browser list pending C06.
Network profile: Monitoring locations and reachability checks pending C08.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Calendar month of agreed service minutes is the existing proposal.
Exclusions: Include planned maintenance until a different exclusion policy is approved.
Measurement method: Successful service minutes / agreed service minutes ×100; retain monitoring and incident evidence.
Pass fail rule: At least 99 percent after the service boundary and measurement rules are approved.
Recovery retention alerts support: Record outage start/end, responsible operator and incident/recovery evidence.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR02 · Interactive performance
Existing proposal: Proposed target: 100 concurrent authenticated users; standard bounded API reads p95 at most 750 ms and p99 at most 1.5 seconds; error rate below 0.5 percent.
Source locator: SRS Version 1.5, NFR02, body after heading at paragraph 1328
Proposed owner: Client performance owner and receiving operator
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Existing proposal: 100 concurrent authenticated users; exact bounded read mix, warm-up, cache and think time pending C08.
Data volumes: Use the NFR04 proposed scale only after dataset mix and distributions are agreed.
User device browser coverage: Client/service test clients separated from agreed browser/device end-to-end checks.
Network profile: Measure service duration separately from client/network elapsed time.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Steady-state run and warm-up duration pending C08.
Exclusions: Report failed/time-out requests; do not remove slow paths without an approved exclusion.
Measurement method: Instrument bounded service reads; report p95, p99, count, errors, workload and environment.
Pass fail rule: Existing proposals: p95≤750 ms, p99≤1.5 s and error rate<0.5 percent at the agreed workload.
Recovery retention alerts support: Retain overload, cancellation and diagnostic evidence with operator routing.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR03 · Spatial performance
Existing proposal: Proposed target: bounded spatial queries p95 at most 2 seconds and p99 at most 4 seconds.
Source locator: SRS Version 1.5, NFR03, body after heading at paragraph 1332
Proposed owner: Client GIS owner and performance specialist
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Bounded spatial query types, geometry complexity, extent, coordinate system and cache state pending C03/C08/E01.
Data volumes: Declare geometry count and complexity; do not infer them from the total feature count.
User device browser coverage: Agreed map/browser clients; supported device matrix pending C06.
Network profile: Record service query duration separately from map transfer and render time.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Repeatable warm/cold query windows pending C08.
Exclusions: Separate unsupported analyses; retain failures and missing/denied outcomes.
Measurement method: Measure the agreed spatial-query set and record all input geometry and environment versions.
Pass fail rule: Existing proposals: p95≤2 s and p99≤4 s for the approved bounded query profile.
Recovery retention alerts support: Bound or cancel expensive work and preserve safe retry status.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR04 · Capacity and scaling
Existing proposal: Proposed sizing: 250 organisations and one million vector features at the agreed workload. Test twice the interactive load for controlled saturation.
Source locator: SRS Version 1.5, NFR04, body after heading at paragraph 1336
Proposed owner: Client data custodians and receiving operator
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Existing proposal: 250 organisations and one million vector features; twice the interactive load for controlled saturation.
Data volumes: Feature types, sizes, document volume, growth, retention and distributions pending C08.
User device browser coverage: Use NFR02/NFR03 agreed clients; field/browser coverage pending C06.
Network profile: Approved network and hosting profile pending C07/C08.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Capacity and saturation test duration pending C08.
Exclusions: Larger volume limits need agreement before procurement; report all bounded rejection/queue outcomes.
Measurement method: Load the approved scale; exercise read/write/spatial mixes and controlled saturation; observe resource growth and integrity.
Pass fail rule: Serve the agreed profile within referenced budgets; reject or queue excess work without corruption, leakage or unbounded memory.
Recovery retention alerts support: Verify recovery after saturation without missing/duplicate accepted outcomes.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR05 · Low bandwidth and responsive use
Existing proposal: Proposed profile: 1.5 Mbps down, 750 Kbps up, 300 ms round trip and 1 percent packet loss. Essential initial transfer at most 1.5 MiB compressed. The system shall support mobile-compatible use of the agreed core journeys on client-agreed devices.
Source locator: SRS Version 1.5, NFR05, body after heading at paragraph 1340
Proposed owner: Client field-access owner and representative users
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Core sign-in, list, detail, form and retry journeys on the agreed responsive interface; no extra phone mock screens.
Data volumes: Essential initial transfer proposal≤1.5 MiB compressed; route/asset boundary pending C08.
User device browser coverage: Client-agreed devices, browsers, viewports and input methods pending C06.
Network profile: Existing proposal: 1.5 Mbps down,750 Kbps up,300 ms round trip,1 percent packet loss.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Per-journey start/end and cold/warm cache states pending C06/C08.
Exclusions: Additional field channel/offline mode is conditional under C01/C06/C07; do not exclude essential responsive core.
Measurement method: Throttle the approved profile; complete each core journey, measure transfer/elapsed time and inspect navigation/errors/retry.
Pass fail rule: All agreed core journeys remain usable on the accepted matrix; meet the existing transfer budget once boundary is approved.
Recovery retention alerts support: Network loss/retry must preserve draft state and honest pending/failure status.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR06 · Accessibility and language
Existing proposal: Proposed web target is WCAG 2.2 AA. Provide keyboard operation, visible focus, labelled controls, readable error messages, text alternatives, accessible tables and text scaling. English, Sinhala and Tamil coverage requires client agreement.
Source locator: SRS Version 1.5, NFR06, body after heading at paragraph 1344
Proposed owner: Client accessibility owner and appointed language reviewers
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Agreed priority journeys and public/authenticated roles; screen-reader and keyboard manual checks.
Data volumes: Representative forms/tables/errors in each agreed language; content set pending C06.
User device browser coverage: Accepted keyboard, screen-reader, browser, device and text-scaling matrix pending C06.
Network profile: Use the agreed core profile where network affects task completion.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Release and changed-journey checks; periodic review cadence pending C06.
Exclusions: Record reasoned exclusions; language or user-group omission requires explicit client decision.
Measurement method: Manual and suitable automated checks against the proposed accessibility criteria, with language/domain review.
Pass fail rule: Existing proposal: WCAG2.2AA for agreed web scope; keyboard/focus/labels/errors/alternatives/tables/scaling pass; translations accepted.
Recovery retention alerts support: Record accessibility/language issue owner, correction and retest.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR07 · Security verification
Existing proposal: Use threat modelling and an agreed OWASP ASVS control set, proposed Level 2. Protect sessions, inputs, files, exports, transport and secrets.
Source locator: SRS Version 1.5, NFR07, body after heading at paragraph 1348
Proposed owner: Appointed security specialist and client authority
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Threat model and agreed verification control set across sessions, inputs, files, exports, transport and secrets.
Data volumes: Synthetic normal, invalid and malicious test payloads within an authorised isolated scope.
User device browser coverage: Agreed channels, browser/device classes and machine clients pending C06/C08.
Network profile: Approved isolated boundaries and origins; no real-system penetration or provider writes.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Release/changed-control scope and security test window pending C08.
Exclusions: Document authorised exclusions and residual findings; no unrecorded high-risk exemption.
Measurement method: Review threat model and execute the agreed security verification cases; proposed control level remains unapproved.
Pass fail rule: No unresolved critical/high security finding at release; other findings have disposition and owner.
Recovery retention alerts support: Incident route, alert delivery, credential/session revocation and retest responsibilities pending C07/C08.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR08 · Data protection
Existing proposal: Collect only information needed for an approved purpose. Apply classification, disclosure limits, retention and rights handling to originals, results, exports and backups.
Source locator: SRS Version 1.5, NFR08, body after heading at paragraph 1352
Proposed owner: Institution data owners and qualified privacy reviewer
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: List,detail,count,map,preview,export,originals,results and backups across denied scopes.
Data volumes: Synthetic personal/sensitive records and permitted summaries; exact retention periods pending C05.
User device browser coverage: All approved access/export channels; assisted/field access included where selected.
Network profile: Approved processing and disclosure boundaries, residency and transfers pending C05/C07.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Before release and each policy/source/classification change; retention schedule pending C05.
Exclusions: No invented lawful basis, blanket consent or public release of restricted originals.
Measurement method: Trace purpose/classification/rights/retention through each copy; execute scope-denial and diagnostic-redaction tests.
Pass fail rule: Collect only approved-purpose data; all denied outputs and diagnostics reveal no restricted content or secrets.
Recovery retention alerts support: Rights requests, removal/retention exceptions, incident receiver and backup handling need C05 decisions.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR09 · Recovery
Existing proposal: Proposed recovery point objective is 24 hours and recovery time objective is 8 hours. Include database, protected files, configuration, keys and spatial resources.
Source locator: SRS Version 1.5, NFR09, body after heading at paragraph 1356
Proposed owner: Receiving operator and client recovery authority
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Coordinated relational/geospatial records, protected files, configuration and keys; usable identity/access checks after restore.
Data volumes: Approved representative release dataset and file set; exact recovery data scale pending C08.
User device browser coverage: Receiving operator tools and agreed user journeys after restoration.
Network profile: Isolated recovery environment and approved backup/restore transfer boundary.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Failure declaration to usable recovered service; objective boundary pending C08.
Exclusions: Backup creation alone is not restore proof; document accepted exclusions and immutable-source limits.
Measurement method: Restore in isolation; reconcile committed records/files/configuration and verify permitted sign-in/access.
Pass fail rule: Existing proposals: recovery point≤24 h and recovery time≤8 h, subject to approved boundary and dataset.
Recovery retention alerts support: Named restore owner, independent backup custody, keys and continuity responsibilities pending C07/C08.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR10 · Reliability
Existing proposal: Commands shall use expected versions and safe retry references. Save a business change and its delivery request reliably together.
Source locator: SRS Version 1.5, NFR10, body after heading at paragraph 1360
Proposed owner: Solution and data-integrity reviewers
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Commands,expected versions,retries,business change plus delivery request,workers and provider outages.
Data volumes: Synthetic duplicate/lost-response/stale-edit/crash/cancellation combinations; scale pending C08.
User device browser coverage: All approved submitting clients and background adapters.
Network profile: Inject connection loss/provider failure only in isolation.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: At each transaction/retry boundary and after restart; duration pending accepted retry policy.
Exclusions: No guessed success after a timeout; distinguish unknown outcome from committed/rejected.
Measurement method: Fault injection and concurrency tests reconcile records,versions,retry IDs and delivery requests.
Pass fail rule: No duplicate or partial committed business outcome; safe conflicts and original evidence retained.
Recovery retention alerts support: Operator can recover or resume the exact prior outcome without editing original evidence.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR11 · Interoperability
Existing proposal: Publish versioned API and data contracts. Declare supported geospatial protocols, encodings, units, coordinate systems and export formats.
Source locator: SRS Version 1.5, NFR11, body after heading at paragraph 1364
Proposed owner: Provider technical owners and receiving integration owner
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Versioned service/data contracts,geospatial formats,units,coordinate systems,pagination and source failure.
Data volumes: Approved bounded message/file sizes and representative mappings; limits pending C04/C08.
User device browser coverage: Approved institutional and application clients/adapters; actual endpoint compatibility pending C04.
Network profile: Only approved endpoints/origins when authorised; this prototype uses local replay.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Contract edition change and scheduled compatibility tests; cadence pending provider agreement.
Exclusions: Unsupported formats/versions remain explicit; no inference of a live interface from a registered URL.
Measurement method: Validate published schemas/errors,unsupported versions,mapping changes,paging,retry and source-failure responses.
Pass fail rule: Only declared versions/formats accepted; failures are safe and reproducible; source/mapping identity preserved.
Recovery retention alerts support: Provider outage/reconciliation/replay owner and adapter support duties pending C04/C07/C08.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR12 · Maintainability and portability
Existing proposal: Keep business definitions configurable, modules separated and dependencies supported. Supply reproducible builds, migrations, operation contracts and complete export.
Source locator: SRS Version 1.5, NFR12, body after heading at paragraph 1368
Proposed owner: Client receiving institution and appointed maintenance team
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Reproducible build,configuration,migration,operation contracts,restore and complete export.
Data volumes: Approved source/configuration/data/file export scope; exact artefact set pending C07.
User device browser coverage: Supported build/maintenance/receiving environments selected under C07.
Network profile: Isolated installation with approved dependency sources; no connection to the real system.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Each release/handover and supported dependency change; support cadence pending C07.
Exclusions: Do not count a developer-only build or sample preview as receiving-team operation.
Measurement method: Receiving team follows supplied instructions to install an isolated copy and reproduce build/restore/migration/export.
Pass fail rule: Business definitions remain configurable; modules remain separate; supported dependencies and complete portable export are demonstrated.
Recovery retention alerts support: Patch,licence,dependency,incident and exit responsibilities recorded in the receiving support plan.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR13 · Audit and observability
Existing proposal: Retain protected business audit separately from redacted diagnostics. Proposed correlation target is at least 99 percent of API requests; significant events queryable within five minutes.
Source locator: SRS Version 1.5, NFR13, body after heading at paragraph 1372
Proposed owner: Security and operations reviewers
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Protected business audit separate from redacted diagnostics; request/action/source/review chains and denied access.
Data volumes: Representative normal/denied/publication/error events; audit retention and capacity pending C05/C08.
User device browser coverage: All approved service clients and operator search tools.
Network profile: Approved audit/alert storage and delivery boundary; no secrets/private source content in diagnostics.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Request sample window and event-query timing pending C08.
Exclusions: Record eligible-request denominator and excluded health/background events explicitly; no hidden missing audit.
Measurement method: Reconcile eligible requests to correlation records; time significant-event queryability and trace source/review/actor.
Pass fail rule: Existing proposals:≥99 percent request correlation and significant events queryable within5min; audit/redaction checks pass.
Recovery retention alerts support: Audit retention,alert receiver,severity,escalation and incident closure pending C05/C07/C08.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
NFR14 · Support and sustainability
Existing proposal: Name the service owner, support levels, escalation, funding, renewal obligations and patch responsibility before operational acceptance.
Source locator: SRS Version 1.5, NFR14, body after heading at paragraph 1376
Proposed owner: Client service owner and receiving operator
Appointed owner: Not confirmed
Owner status: Pending C07/C08; institution roles not appointed by this annex
Workload: Service/support levels,escalation,funding,renewal,patching,continuity and knowledge transfer.
Data volumes: Accepted service/module/dependency inventory,users and source commitments; scope pending C01/C07.
User device browser coverage: Receiving support and user-training environments; actual skills/device coverage pending C06/C07.
Network profile: Hosting/support/provider access and continuity routes pending C07.
Language accessibility coverage: English/Sinhala/Tamil and accessibility scope pending C06; apply the agreed NFR06 matrix.
Service boundary: Future agreed service and dependent storage/adapters; current browser mock does not establish this service boundary.
Measurement window: Before operational acceptance; review/renewal/escalation schedules pending contract.
Exclusions: No invented budget,staff appointment,response SLA or supplier commitment.
Measurement method: Review the costed support plan and dependency inventory; exercise incident routing,continuity and receiving-team knowledge transfer.
Pass fail rule: Named authority accepts a funded support/renewal/patch plan and completed continuity/knowledge-transfer evidence.
Recovery retention alerts support: Receiving operator owns escalation,continuity,patching and supported exit under C07/C08.
Proposal status: Existing target/condition proposal; acceptance configuration pending
Accepted values: Not approved in available evidence
Observed prototype measurement: Not measured for this operational boundary; candidate mock checks are recorded separately.
Decision references: C05; C06; C07; C08
Result status: Not executed — future operational acceptance
Institutional decision status: Pending in Institution review only
Release and candidate options
Proposed core requirements: 179. Whole conditional options: 11. Evidenced accepted requirements: 0; acceptance remains unknown for all 190. No formal deferral is recorded without authority. Optional branches in core requirements remain separately conditional.
| Item | Proposed treatment | Decision and dependency |
|---|---|---|
| FR029 · Describe each source and dataset | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR030 · Describe versioned fields | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR031 · Define indicators before results | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR032 · Separate original input from curated data | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR033 · Follow up with the provider | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR034 · Connect usable fields to sources | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR035 · Use controlled entry routes | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR036 · Follow configured transitions | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR037 · Keep submission context | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR038 · Keep manual source details | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR039 · Keep missing values distinct | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR040 · Reuse detailed field forms | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR041 · Validate a batch before confirmation | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR042 · Approve and save the batch safely | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR043 · Keep the import history | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR044 · Recover repeated upload results safely | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR045 · Provide one common file parser | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR046 · Register the original purpose | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04; C05C01; C11; C02; C04; C05 |
| FR047 · Gate real AI processing | Conditional optionConditional option; decision pending | C01; C11; C02; C04; C05; C06; C07C01; C11; C02; C04; C05; C06; C07 |
| FR048 · Keep extraction evidence | Conditional optionConditional option; decision pending | C01; C11; C02; C04; C05; C06; C07C01; C11; C02; C04; C05; C06; C07 |
| FR049 · Review several domains from one document | Conditional optionConditional option; decision pending | C01; C11; C02; C04; C05; C06; C07C01; C11; C02; C04; C05; C06; C07 |
| FR050 · Keep mapping approval separate from acceptance | Conditional optionConditional option; decision pending | C01; C11; C02; C04; C05; C06; C07C01; C11; C02; C04; C05; C06; C07 |
| FR051 · Register a controlled source feed | Conditional optionConditional option; decision pending | C01; C11; C02; C04; C06; C07C01; C11; C02; C04; C06; C07 |
| FR052 · Review provider mappings | Conditional optionConditional option; decision pending | C01; C11; C02; C04; C06; C07C01; C11; C02; C04; C06; C07 |
| FR053 · Decode supported provider formats | Conditional optionConditional option; decision pending | C01; C11; C02; C04; C06; C07C01; C11; C02; C04; C06; C07 |
| FR054 · Keep honest row outcomes | Conditional optionConditional option; decision pending | C01; C11; C02; C04; C06; C07C01; C11; C02; C04; C06; C07 |
| FR055 · Prevent repeated source events | Conditional optionConditional option; decision pending | C01; C11; C02; C04; C06; C07C01; C11; C02; C04; C06; C07 |
| FR056 · Keep live activation explicit | Conditional optionConditional option; decision pending | C01; C11; C02; C04; C06; C07C01; C11; C02; C04; C06; C07 |
| FR057 · Track quality issues and corrections | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR058 · Apply published field rules | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR059 · Review candidate identity links | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR060 · Keep differing values from each source | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR061 · Limit preferred source decisions | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR062 · Reuse the quality worklist | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04C01; C11; C02; C04 |
| FR001 · Maintain organizations and people | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR002 · Manage accounts and roles | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR003 · Limit delegated powers | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR004 · Use standard secure sign in | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR005 · Use the signed in user identity | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR006 · Invite the intended user | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR007 · Keep the user identity when changing workspace | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR008 · Use one connected platform | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR009 · Check the full access scope | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR010 · Let owners control sharing | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR011 · Place all stakeholders correctly | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR012 · Keep separate owned base domains | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR013 · Configure useful workspaces | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR014 · Maintain versioned domain packs | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR015 · Allow safe configuration only | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR016 · Keep the original form version | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR017 · Separate editable settings from software changes | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR018 · Maintain editable vocabularies | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR019 · Allow several domain classifications | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR020 · Keep business terms in configuration | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR021 · Review meanings and impacts | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05C01; C11; C02; C05 |
| FR022 · Support several geography schemes | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR023 · Keep place identity and source | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR024 · Link overlapping places | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR025 · Preserve boundary history | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR026 · Validate spatial input | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR027 · Review boundary changes | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR028 · Search GN divisions within safe limits | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR063 · Describe spatial sources | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR064 · Save permitted map settings | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR065 · Reuse one spatial catalogue | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR066 · Protect location disclosure | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04; C05C01; C11; C02; C03; C04; C05 |
| FR067 · Exclude known demonstration features | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR068 · Keep navigation and large maps simple | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR069 · Provide bounded vector exploration | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04; E01C01; C11; C02; C03; C04; E01 |
| FR070 · Use genuine points for point methods | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04; E01C01; C11; C02; C03; C04; E01 |
| FR071 · Compare compatible raster cells | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04; E01C01; C11; C02; C03; C04; E01 |
| FR072 · Retain an exploratory receipt | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04; E01C01; C11; C02; C03; C04; E01 |
| FR073 · Retain normalized spatial sources | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR074 · Review spatial release separately | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| FR075 · Keep weather source identities | Proposed MustProposed release baseline; not accepted | C01; C11; C03; C04; E01C01; C11; C03; C04; E01 |
| FR076 · Show missing and stale weather honestly | Proposed MustProposed release baseline; not accepted | C01; C11; C03; C04; E01C01; C11; C03; C04; E01 |
| FR077 · Keep retained rainfall at its actual scale | Proposed MustProposed release baseline; not accepted | C01; C11; C03; C04; E01C01; C11; C03; C04; E01 |
| FR078 · Do not invent the GN time series | Proposed MustProposed release baseline; not accepted | C01; C11; C03; C04; E01C01; C11; C03; C04; E01 |
| FR079 · Separate evidence from warnings | Proposed MustProposed release baseline; not accepted | C01; C11; C03; C04; E01C01; C11; C03; C04; E01 |
| FR080 · Keep farming identities and plots | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04; E01; E02C01; C11; C02; C04; E01; E02 |
| FR081 · Record farm work and issues | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04; E01; E02C01; C11; C02; C04; E01; E02 |
| SH-GEO-FEAT-001 · Register Geographic Information Types | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-002 · Create Geographic Records from a Map | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-003 · Record Unknown or Approximate Locations | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-004 · Support Different Geographic Roles | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-005 · Use Domain-Specific Attributes | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-006 · Accept Multiple Geographic Data Sources | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-007 · Validate Geographic Information | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-008 · Review Geographic Records | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-009 · Preserve Source Ownership | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-010 · Maintain Geographic History | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-011 · Support Geographic Time Periods | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-012 · Reuse Existing GIS Layers | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-013 · Configure Map Symbols and Legends | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-014 · Support Geographic Analysis | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04; E01C01; C11; C02; C03; C04; E01 |
| SH-GEO-FEAT-015 · Connect Geographic Records to Other Modules | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-016 · Support Data Maintenance | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-017 · Support responsive geographic collection | Proposed Must with conditional option branchProposed core with conditional option branch; not accepted | C01; C11; C02; C03; C04; C06; C07C01; C11; C02; C03; C04; C06; C07 |
| SH-GEO-FEAT-018 · Show Geographic Data Quality and Status | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04C01; C11; C02; C03; C04 |
| SH-GEO-FEAT-019 · Protect restricted geographic information | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04; C05C01; C11; C02; C03; C04; C05 |
| SH-GEO-FEAT-020 · Distinguish Facts from Assessments and Warnings | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C03; C04; E01C01; C11; C02; C03; C04; E01 |
| FR094 · Build reusable report questions | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR095 · Keep report sources and access rules | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR096 · Review how datasets will be combined | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR097 · Show unmatched and invalid inputs | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR098 · Save report definitions and results | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR099 · Use suitable visuals and source maps | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR100 · Export reports with sources and review history | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR101 · Show what a decision needs | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR102 · Calculate an approved criteria score | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR103 · Check differences and thresholds safely | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR104 · Route a reviewed finding only when configured | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR105 · Record the human decision | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR106 · Use actual evidence and current guidance | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR107 · Require independent review and approved methods | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05; E01C01; C11; C04; C05; E01 |
| FR108 · Register the programme or project | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR109 · Connect domains and areas once | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR110 · Organize implementation | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR111 · Link project evidence | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR112 · Onboard ongoing and completed projects | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR113 · Keep versions of major project changes | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR114 · Follow the project from setup to closure | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR115 · Record each project step and its owner | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR116 · Keep task submissions and review records linked | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR117 · Generate scheduled tasks once | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR118 · Record who must deliver each item | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR119 · Return and correct with a reason | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR120 · Show only permitted assigned work | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR121 · Keep required review independent | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR122 · Connect protected feedback to action | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR123 · Approve the monitoring plan | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR124 · Allow honest baseline and target states | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR125 · Execute a repeatable reviewed method | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR126 · Reconcile closure across the project | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR127 · Verify or waive each closure check properly | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR128 · Allow closure only after required checks | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR090 · Reuse asset and connection records | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR091 · Retain handover and maintenance evidence | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C10; C12C01; C11; C02; C10; C12 |
| FR086 · Reuse participant identities | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05; C09C01; C11; C02; C05; C09 |
| FR087 · Record support and training history | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05; C09C01; C11; C02; C05; C09 |
| FR088 · Connect products producers and buyers | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05; C09C01; C11; C02; C05; C09 |
| FR089 · Keep livelihood outcomes separate | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05; C09C01; C11; C02; C05; C09 |
| FR129 · Catalogue documents and media | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05; C09C01; C11; C02; C05; C09 |
| FR130 · Protect originals and derived files | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05; C09C01; C11; C02; C05; C09 |
| FR131 · Scan and authorize file use | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05; C09C01; C11; C02; C05; C09 |
| FR132 · Review knowledge publication | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05; C09C01; C11; C02; C05; C09 |
| FR133 · Retain eligible citations | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05; C09C01; C11; C02; C05; C09 |
| FR134 · Offer a simple beneficiary view | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05; C09C01; C11; C02; C05; C09 |
| FR135 · Keep anonymous intake closed until approved | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C05; C09C01; C11; C02; C05; C09 |
| FR082 · Keep harvest and sale evidence | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04; E01; E02C01; C11; C02; C04; E01; E02 |
| FR083 · Keep origin and currency explicit | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04; E01; E02C01; C11; C02; C04; E01; E02 |
| FR084 · Compare only compatible market evidence | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04; E01; E02C01; C11; C02; C04; E01; E02 |
| FR085 · Use accepted seasonal arithmetic | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04; E01; E02C01; C11; C02; C04; E01; E02 |
| FR092 · Keep PES frameworks controlled | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04; E03C01; C11; C02; C04; E03 |
| FR093 · Trace programme connections | Proposed MustProposed release baseline; not accepted | C01; C11; C02; C04; E03C01; C11; C02; C04; E03 |
| FR136 · Use the API for all web actions | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08; C06C01; C11; C07; C08; C06 |
| FR137 · Keep workflows simple and accessible | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08; C06C01; C11; C07; C08; C06 |
| FR138 · Use approved choices and language resources | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08; C06C01; C11; C07; C08; C06 |
| FR139 · Protect sign in across approved access channels | Proposed Must with conditional option branchProposed core with conditional option branch; not accepted | C01; C11; C07; C08; C06C01; C11; C07; C08; C06 |
| FR140 · Capture permitted field evidence | Proposed Must with conditional option branchProposed core with conditional option branch; not accepted | C01; C11; C07; C08; C06C01; C11; C07; C08; C06 |
| FR141 · Control optional offline submission | Conditional optionConditional option; decision pending | C01; C11; C07; C08; C06C01; C11; C07; C08; C06 |
| FR142 · Explain the architecture through real workflows | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| FR143 · Expose controlled API contracts | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| FR144 · Bound work and return safe errors | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| FR145 · Prevent duplicate requests and conflicting edits | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| FR146 · Protect transport and endpoints | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| FR155 · Separate interface and hosting responsibilities | Proposed Must with conditional option branchProposed core with conditional option branch; not accepted | C01; C11; C07; C08; C06C01; C11; C07; C08; C06 |
| FR147 · Use approved operations to access data | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| FR148 · Keep action history and source links | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| NFR01 · Availability | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| NFR02 · Interactive performance | Proposed MustProposed release baseline; not accepted | C01; C11; C08C01; C11; C08 |
| NFR03 · Spatial performance | Proposed MustProposed release baseline; not accepted | C01; C11; C03; C08C01; C11; C03; C08 |
| NFR04 · Capacity and scaling | Proposed MustProposed release baseline; not accepted | C01; C11; C08C01; C11; C08 |
| NFR05 · Low bandwidth and responsive use | Proposed MustProposed release baseline; not accepted | C01; C11; C06; C08C01; C11; C06; C08 |
| NFR06 · Accessibility and language | Proposed MustProposed release baseline; not accepted | C01; C11; C06C01; C11; C06 |
| NFR07 · Security verification | Proposed MustProposed release baseline; not accepted | C01; C11; C05; C08C01; C11; C05; C08 |
| NFR08 · Data protection | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C05C01; C11; C04; C05 |
| NFR09 · Recovery | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| NFR10 · Reliability | Proposed MustProposed release baseline; not accepted | C01; C11; C08C01; C11; C08 |
| NFR11 · Interoperability | Proposed MustProposed release baseline; not accepted | C01; C11; C04; C07C01; C11; C04; C07 |
| NFR12 · Maintainability and portability | Proposed MustProposed release baseline; not accepted | C01; C11; C07C01; C11; C07 |
| NFR13 · Audit and observability | Proposed MustProposed release baseline; not accepted | C01; C11; C05; C08C01; C11; C05; C08 |
| NFR14 · Support and sustainability | Proposed MustProposed release baseline; not accepted | C01; C11; C07C01; C11; C07 |
| FR149 · Protect discovery and notification delivery | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| FR151 · Separate environments and secrets | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| FR152 · Monitor service health without exposing private data | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| FR153 · Release through controlled runbooks | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| FR154 · Prove coordinated recovery | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| FR150 · Govern change and trace requirements | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| FR156 · List software gaps and missing external decisions separately | Proposed MustProposed release baseline; not accepted | C01; C11; C07; C08C01; C11; C07; C08 |
| DEC-DP01-001 · Land change | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-002 · Development screening | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-003 · Planning coverage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-004 · Field verification | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-005 · Agricultural suitability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-006 · Land conversion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-007 · Settlement planning | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-008 · Idle land | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-009 · Wetland protection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-010 · Riparian protection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-011 · Tenure conflicts | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-012 · Fragmentation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-013 · Urban expansion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-014 · Service access | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-015 · Restoration planning | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-016 · Land degradation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-017 · Plan implementation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-018 · Public consultation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-019 · Map documentation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP01-020 · Survey scheduling | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-001 · Erosion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-002 · Conservation treatments | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-003 · Erosion classes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-004 · Soil carbon | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-005 · Soil fertility | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-006 · Salinity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-007 · Soil compaction | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-008 · Infiltration | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-009 · Water harvesting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-010 · On-farm irrigation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-011 · Watershed treatments | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-012 · Conservation inspection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-013 · Agroclimate advice | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-014 · Monitoring network | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-015 · Crop suitability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-016 · Demonstration trials | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-017 · Conservation economics | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-018 · Soil contamination | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-019 · Technical dissemination | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP02-020 · Model assurance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-001 · Seed adoption | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-002 · Production costs | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-003 · Irrigation advice | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-004 · Planting guidance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-005 · Variety selection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-006 · Yield gaps | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-007 · Pest surveillance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-008 · Disease management | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-009 · Seed certification | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-010 · Seed supply | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-011 · Fertilizer advice | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-012 · Pesticide stewardship | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-013 · Extension delivery | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-014 · Post-harvest loss | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-015 · Mechanization | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-016 · Crop diversification | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-017 · Farm income | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-018 · Weather losses | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-019 · Advisory effectiveness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP03-020 · Research trials | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-001 · Paddy utilization | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-002 · Support overlap | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-003 · Minor irrigation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-004 · Agrarian services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-005 · Paddy register | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-006 · Cultivation disputes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-007 · Land conversion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-008 · Tank rehabilitation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-009 · Farmer organizations | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-010 · Organization finance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-011 · Crop damage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-012 · Subsidy administration | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-013 · Input distribution | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-014 · Service centres | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-015 · Canal maintenance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-016 · Farmer participation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-017 · Tank reservations | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-018 · Irrigation equity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-019 · Registry updates | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP04-020 · Service outcomes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-001 · Command water demand | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-002 · Gauge operations | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-003 · Canal performance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-004 · Reservoir operation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-005 · Dam safety | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-006 · Flood readiness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-007 · Drought allocation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-008 · Reservoir sedimentation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-009 · Canal rehabilitation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-010 · Drainage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-011 · Salinity exclusion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-012 · Gate scheduling | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-013 · Water productivity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-014 · Environmental flows | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-015 · Hydrological models | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-016 · Pumping systems | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-017 · Rehabilitation investment | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-018 · Construction delivery | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-019 · Spare parts | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP05-020 · Public information | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-001 · Seasonal cropping | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-002 · Water delivery | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-003 · Reservoir networks | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-004 · Planning evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-005 · Multi-sector allocation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-006 · Drought response | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-007 · Land allocation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-008 · Land conversion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-009 · Reservation protection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-010 · Farmer livelihoods | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-011 · System productivity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-012 · Crop diversification | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-013 · Irrigation assets | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-014 · Settlement services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-015 · Environmental restoration | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-016 · Aquaculture coordination | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-017 · Flood operations | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-018 · Investment delivery | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-019 · Public consultation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP06-020 · System reporting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-001 · Forest cover | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-002 · Forest inventory | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-003 · Restoration survival | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-004 · Forest alerts | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-005 · Fire preparedness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-006 · Encroachment | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-007 · Restoration selection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-008 · Species selection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-009 · Nursery supply | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-010 · Seed provenance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-011 · Invasive plants | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-012 · Watershed protection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-013 · Forest carbon | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-014 · Community forestry | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-015 · Timber authorization | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-016 · Plantation management | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-017 · Ecotourism | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-018 · Biodiversity monitoring | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-019 · Patrol deployment | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP07-020 · Forest records | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-001 · Rainfall anomalies | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-002 · Dry and wet spells | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-003 · Station completeness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-004 · Drought monitoring | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-005 · Temperature extremes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-006 · Severe weather | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-007 · Forecast verification | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-008 · Seasonal forecasts | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-009 · Station siting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-010 · Instrument maintenance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-011 · Data homogenization | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-012 · Agrometeorology | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-013 · Evapotranspiration | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-014 · Marine services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-015 · Aviation services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-016 · Lightning exposure | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-017 · Climate trends | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-018 · Observation reconciliation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-019 · Climate requests | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP08-020 · Forecast publication | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-001 · Crop economics | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-002 · Market opportunities | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-003 · Post-harvest quality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-004 · Crop productivity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-005 · Crop suitability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-006 · Planting materials | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-007 · Plant health | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-008 · Quality compliance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-009 · Replanting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-010 · Extension coverage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-011 · Certification readiness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-012 · Value addition | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-013 · Traceability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-014 · Harvest timing | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-015 · Climate adaptation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-016 · Subsidy follow-up | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-017 · Research priorities | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-018 · Soil conservation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-019 · Grower records | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP09-020 · Programme evaluation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-001 · Variety adoption | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-002 · Irrigation classes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-003 · Input costs | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-004 · Sowing progress | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-005 · Provincial production | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-006 · Pest response | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-007 · Extension staffing | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-008 · Seed distribution | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-009 · Soil testing | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-010 · Demonstration farms | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-011 · Training outcomes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-012 · Crop damage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-013 · Mechanization access | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-014 · Water-saving practices | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-015 · Diversification | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-016 · Horticulture | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-017 · Budget delivery | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-018 · Service inclusion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-019 · Reporting consistency | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP10-020 · Provincial outcomes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-001 · Output verification | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-002 · Delivery performance | Candidate only — awaiting scope confirmationProposed; awaiting PMU scope confirmation | C01; C02; C10; C11; C12Accepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-003 · Reporting bottlenecks | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-004 · Intervention overlap | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-005 · Annual planning | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-006 · Funding commitments | Candidate only — awaiting scope confirmationProposed; awaiting PMU scope confirmation | C01; C02; C10; C11; C12Accepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-007 · Procurement scheduling | Candidate only — awaiting scope confirmationProposed; awaiting PMU scope confirmation | C01; C02; C10; C11; C12Accepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-008 · Contract performance | Candidate only — awaiting scope confirmationProposed; awaiting PMU scope confirmation | C01; C02; C10; C11; C12Accepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-009 · Safeguards | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-010 · Grievances | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-011 · Participation equity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-012 · Change control | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-013 · Decision conditions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-014 · Partner coordination | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-015 · Outcome evaluation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-016 · Risk financing | Candidate only — awaiting scope confirmationProposed; awaiting PMU scope confirmation | C01; C02; C10; C11; C12Accepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-017 · Asset handover | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-018 · Learning and scaling | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-019 · Evidence catalogue | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP11-020 · Project closure | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-001 · Ecosystem change | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-002 · Soil-carbon monitoring | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-003 · Biodiversity evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-004 · Forest-carbon estimates | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-005 · Landscape restoration | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-006 · Agroforestry design | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-007 · Research design | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-008 · Sampling allocation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-009 · Data harmonization | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-010 · Model validation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-011 · Hydrological evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-012 · Ecosystem services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-013 · Trade-offs | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-014 · Carbon uncertainty | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-015 · Community knowledge | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-016 · Gender and inclusion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-017 · Long-term monitoring | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-018 · Open science | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-019 · Knowledge products | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP12-020 · Research translation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-001 · Field assignments | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-002 · Monitoring coverage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-003 · Community cases | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-004 · Spatial verification | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-005 · Watershed plans | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-006 · Intervention scheduling | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-007 · Restoration follow-up | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-008 · Conservation works | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-009 · Water problems | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-010 · Farmer practice uptake | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-011 · Local hazards | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-012 · Team workload | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-013 · Safeguard conditions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-014 · Equipment logistics | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-015 · Community consultation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-016 · Progress exceptions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-017 · Access routes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-018 · Support duplication | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-019 · Field form quality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP13-020 · Local outcomes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-001 · Boundary selection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-002 · Parcel reconciliation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-003 · Terrain screening | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-004 · Field verification | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-005 · Cadastral backlog | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-006 · Control network | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-007 · Coordinate transformation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-008 · Survey accuracy | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-009 · Aerial acquisition | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-010 · Boundary disputes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-011 · Topographic updates | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-012 · Survey permissions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-013 · Elevation products | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-014 · Encroachment surveys | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-015 · Survey resources | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-016 · Map delivery | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-017 · Land information | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-018 · Survey cost | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-019 · Map distribution | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP14-020 · Historical integrity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-001 · Published services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-002 · Metadata currency | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-003 · Semantic conflicts | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-004 · Withdrawn rights | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-005 · Service onboarding | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-006 · Coordinate standards | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-007 · National coverage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-008 · Geometry quality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-009 · Service performance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-010 · Schema changes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-011 · Data lineage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-012 · Duplicate catalogues | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-013 · Sensitive layers | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-014 · Interoperability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-015 · Incident response | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-016 · Update scheduling | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-017 · Catalogue discovery | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-018 · Spatial joins | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-019 · Usage requests | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP15-020 · Disaster resilience | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-001 · Affected households | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-002 · Damage and loss | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-003 · Safe centres | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-004 · Recovery funding | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-005 · Warning dissemination | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-006 · Evacuation planning | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-007 · Emergency resources | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-008 · Relief distribution | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-009 · Relief stocks | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-010 · Preparedness drills | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-011 · Risk reduction | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-012 · Critical facilities | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-013 · Rapid assessments | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-014 · Response coordination | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-015 · Recovery progress | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-016 · Impact trends | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-017 · Contingency plans | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-018 · Public information | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-019 · Response evaluation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP16-020 · Incident records | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-001 · Site clearance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-002 · Hazard-map updates | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-003 · Asset exposure | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-004 · Rainfall investigations | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-005 · Slope inspections | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-006 · Monitoring systems | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-007 · Slope stabilization | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-008 · Relocation assessment | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-009 · Construction conditions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-010 · Geotechnical evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-011 · Early warning evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-012 · Laboratory workload | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-013 · Road slopes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-014 · Post-event inspection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-015 · Drainage remediation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-016 · Model validation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-017 · Mitigation outcomes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-018 · Land-use advice | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-019 · Community awareness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP17-020 · Case administration | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-001 · Water pollution | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-002 · Sampling coverage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-003 · Mitigation compliance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-004 · Water anomalies | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-005 · Environmental licensing | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-006 · License renewal | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-007 · Environmental assessment | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-008 · Air pollution | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-009 · Noise complaints | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-010 · Industrial effluent | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-011 · Waste management | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-012 · Hazardous waste | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-013 · Wetland conservation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-014 · Public complaints | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-015 · Inspection targeting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-016 · Incident response | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-017 · Environmental education | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-018 · Restoration outcomes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-019 · Laboratory evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP18-020 · Environmental records | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-001 · Survey coverage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-002 · Wildlife incidents | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-003 · Habitat exposure | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-004 · Threat reduction | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-005 · Human-elephant conflict | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-006 · Fence maintenance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-007 · Wildlife corridors | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-008 · Poaching response | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-009 · Patrol coverage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-010 · Invasive species | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-011 · Visitor management | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-012 · Research permissions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-013 · Sensitive information | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-014 · Habitat restoration | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-015 · Population monitoring | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-016 · Wildlife health | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-017 · Rescue capacity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-018 · Community outreach | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-019 · Conservation effectiveness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP19-020 · Protected-area records | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-001 · Agricultural patterns | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-002 · Poverty reporting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-003 · Small-area reporting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-004 · Statistical revisions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-005 · Survey design | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-006 · Nonresponse | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-007 · Frame quality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-008 · Questionnaire quality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-009 · Field deployment | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-010 · Confidentiality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-011 · Method comparability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-012 · Release scheduling | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-013 · Crop estimates | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-014 · Price statistics | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-015 · Labour statistics | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-016 · Demographic change | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-017 · Administrative sources | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-018 · Data access services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-019 · Reproducible estimates | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP20-020 · Classification maintenance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-001 · Groundwater depletion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-002 · Seasonal groundwater | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-003 · Groundwater quality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-004 · Monitoring coverage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-005 · Borehole siting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-006 · Pumping tests | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-007 · Abstraction balance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-008 · Well protection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-009 · Saline intrusion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-010 · Industrial abstraction | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-011 · Recharge options | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-012 · Mining impacts | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-013 · Well rehabilitation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-014 · Laboratory turnaround | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-015 · Drought supply | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-016 · Drilling performance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-017 · Monitoring devices | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-018 · Public evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-019 · Aquifer models | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP21-020 · Well registry | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-001 · Non-revenue water | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-002 · Leakage management | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-003 · Service expansion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-004 · Water quality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-005 · Water safety planning | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-006 · Treatment capacity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-007 · Pressure management | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-008 · Pipe replacement | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-009 · Pump efficiency | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-010 · Meter replacement | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-011 · Supply interruptions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-012 · Source security | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-013 · Connection requests | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-014 · Customer complaints | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-015 · Chemical supply | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-016 · Wastewater treatment | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-017 · Sewer overflows | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-018 · Capital investments | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-019 · Community systems | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP22-020 · Network records | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-001 · Geological constraints | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-002 · Mapping coverage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-003 · Site investigation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-004 · Map revisions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-005 · Mining licenses | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-006 · Extraction monitoring | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-007 · Mine rehabilitation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-008 · River sand | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-009 · Quarry impacts | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-010 · Illegal extraction | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-011 · Mineral resources | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-012 · Groundwater interactions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-013 · Laboratory services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-014 · Sample integrity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-015 · Transport permissions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-016 · Mine inspections | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-017 · Revenue reconciliation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-018 · Geohazard evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-019 · Resource estimates | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP23-020 · Geological catalogue | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-001 · Land applications | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-002 · Lease reviews | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-003 · Digitization | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-004 · Processing performance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-005 · Land allocation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-006 · Boundary reconciliation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-007 · Lease revenue | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-008 · Arrears follow-up | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-009 · Permit conditions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-010 · Succession cases | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-011 · Public-purpose land | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-012 · Land disputes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-013 · Land reservations | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-014 · Institutional handover | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-015 · Unauthorized occupation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-016 · Valuation review | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-017 · Land-use effectiveness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-018 · Record access | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-019 · Document quality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP24-020 · Office capacity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-001 · Price spreads | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-002 · Price volatility | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-003 · Seasonal markets | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-004 · Market comparisons | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-005 · Market coverage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-006 · Food affordability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-007 · Farmer returns | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-008 · Marketing losses | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-009 · Market integration | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-010 · Policy evaluation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-011 · Input markets | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-012 · Farmer organization research | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-013 · Land and labour | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-014 · Food supply disruptions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-015 · Storage investments | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-016 · Survey design | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-017 · Publication quality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-018 · Training priorities | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-019 · Research requests | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP25-020 · Evidence reproducibility | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-001 · Export destinations | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-002 · Market dependence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-003 · Growth opportunities | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-004 · Unit values | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-005 · Exporter readiness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-006 · Market access | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-007 · Trade promotion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-008 · Buyer matching | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-009 · Export diversification | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-010 · Exporter development | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-011 · Quality failures | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-012 · Brand development | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-013 · Promotion outcomes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-014 · Trade barriers | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-015 · Digital channels | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-016 · Sustainable exports | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-017 · Logistics constraints | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-018 · Support funding | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-019 · Exporter directory | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP26-020 · Export policy impact | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-001 · Support uptake | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-002 · Training progression | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-003 · Service delays | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-004 · Geographic reach | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-005 · Business viability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-006 · Finance referral | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-007 · Mentoring | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-008 · Market linkages | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-009 · Enterprise survival | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-010 · Business performance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-011 · Women and youth support | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-012 · Grant administration | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-013 · Duplicate assistance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-014 · Business skills | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-015 · Formalization support | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-016 · Climate resilience | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-017 · Incubation capacity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-018 · Programme finance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-019 · Enterprise registry | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP27-020 · Programme effectiveness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-001 · Estate plots | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-002 · Infrastructure readiness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-003 · Support outcomes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-004 · Estate requests | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-005 · Technology upgrades | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-006 · Resource productivity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-007 · Product quality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-008 · Industrial training | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-009 · New enterprise appraisal | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-010 · Estate maintenance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-011 · Rent reconciliation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-012 · Pollution referrals | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-013 · Common facilities | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-014 · Product development | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-015 · Testing services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-016 · Supply-chain linkages | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-017 · Worker safety | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-018 · Estate expansion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-019 · Estate catalogue | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP28-020 · Industrial outcomes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-001 · District projects | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-002 · Citizen services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-003 · Intervention coverage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-004 · District reporting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-005 · District planning | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-006 · Disaster coordination | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-007 · Funding coordination | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-008 · Land coordination | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-009 · Infrastructure access | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-010 · Beneficiary overlap | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-011 · Safeguard follow-up | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-012 · Divisional capacity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-013 · District grievances | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-014 · Public consultation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-015 · Programme inclusion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-016 · Procurement dependencies | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-017 · Asset handover | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-018 · Outcome reporting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-019 · Geographic consistency | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP29-020 · Inter-agency decisions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-001 · Administrative applications | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-002 · Service standards | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-003 · Programme gaps | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-004 · Grama Niladhari returns | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-005 · State-land referrals | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-006 · Disaster relief | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-007 · Social-service referrals | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-008 · Certificate services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-009 · Local development | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-010 · Community consultation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-011 · Field inspections | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-012 · Financial assistance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-013 · Service inclusion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-014 · Citizen complaints | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-015 · Project monitoring | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-016 · Public assets | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-017 · Data reconciliation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-018 · Office workload | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-019 · Local reporting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP30-020 · Referral completion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-001 · Field reporting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-002 · Community observations | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-003 · Case corrections | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-004 · Asset locations | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-005 · Disaster impacts | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-006 · Relief referrals | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-007 · Duplicate assistance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-008 · Household updates | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-009 · Certificate evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-010 · Vulnerable residents | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-011 · Community complaints | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-012 · Public warnings | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-013 · Community meetings | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-014 · Local infrastructure | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-015 · Land observations | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-016 · Field visits | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-017 · Programme follow-up | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-018 · Record privacy | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-019 · Boundary codes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP31-020 · Service feedback | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-001 · Land use | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-002 · Support fairness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-003 · Irrigation requests | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-004 · Service coordination | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-005 · Water rotations | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-006 · Tail-end equity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-007 · Collective inputs | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-008 · Collective marketing | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-009 · Machinery sharing | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-010 · Irrigation upkeep | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-011 · Group finance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-012 · Membership | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-013 · Governance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-014 · Training | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-015 · Drought plans | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-016 · Crop-loss evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-017 · Storage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-018 · Participation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-019 · Member communication | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP32-020 · Collective outcomes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-001 · Farm profitability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-002 · Irrigation planning | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-003 · Harvest losses | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-004 · Planting dates | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-005 · Crop choice | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-006 · Input budgeting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-007 · Cash needs | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-008 · Soil advice | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-009 · Pest diagnosis | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-010 · Safe crop protection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-011 · Seed purchase | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-012 · Labour planning | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-013 · Machinery choice | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-014 · Selling decisions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-015 · Buyer matching | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-016 · Drought adaptation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-017 · Storage decisions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-018 · Farm investment | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-019 · Support applications | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP33-020 · Farm recordkeeping | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-001 · Production economics | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-002 · Soil and water | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-003 · Replanting areas | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-004 · Worker services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-005 · Crop suitability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-006 · Planting survival | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-007 · Erosion control | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-008 · Harvest scheduling | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-009 · Pest management | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-010 · Processing efficiency | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-011 · Energy and water | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-012 · Product quality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-013 · Climate resilience | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-014 · Worker safety | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-015 · Water and housing | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-016 · Maintenance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-017 · Traceability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-018 · Carbon evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-019 · Community consultation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP34-020 · Estate classifications | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-001 · Training and services | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-002 · Issue follow-up | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-003 · Programme overlap | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-004 · Verified outcomes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-005 · Drinking water | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-006 · Sanitation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-007 · Housing safety | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-008 · Childcare access | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-009 · Health referrals | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-010 · Skills development | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-011 · Livelihood alternatives | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-012 · Workplace concerns | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-013 · Service accessibility | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-014 · Disaster preparedness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-015 · Participation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-016 · Community facilities | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-017 · Support eligibility | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-018 · Community funds | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-019 · Communication | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP35-020 · Privacy and safeguarding | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-001 · Supply matching | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-002 · Procurement prices | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-003 · Trading spreads | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-004 · Delivery commitments | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-005 · Supplier reliability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-006 · Product acceptance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-007 · Stock management | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-008 · Spoilage reduction | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-009 · Transport planning | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-010 · Storage choice | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-011 · Trading cash flow | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-012 · Buyer payments | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-013 · Customer dependence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-014 · Supplier dependence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-015 · Price variability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-016 · Traceability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-017 · Market expansion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-018 · Contract readiness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-019 · Packaging choices | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP36-020 · Product catalogue | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-001 · Processing yield | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-002 · Logistics costs | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-003 · Cold chain | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-004 · Export performance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-005 · Raw materials | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-006 · Capacity planning | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-007 · Production scheduling | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-008 · Quality assurance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-009 · Traceability and recall | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-010 · Food loss | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-011 · Energy efficiency | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-012 · Water efficiency | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-013 · Equipment reliability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-014 · Inventory expiry | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-015 · Packaging compliance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-016 · Working capital | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-017 · Expansion appraisal | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-018 · Export documentation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-019 · Workforce capability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP37-020 · Process records | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-001 · Investment appraisal | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-002 · Repayment capacity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-003 · Co-financing | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-004 · Sensitivity | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-005 · Climate risk | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-006 · Environmental and social risk | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-007 · Green taxonomy | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-008 · Credit evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-009 · Seasonal lending | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-010 · Portfolio concentration | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-011 · Arrears management | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-012 · Collateral review | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-013 · Disbursement conditions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-014 · Impact claims | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-015 · Application processing | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-016 · Guarantee programmes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-017 · Financial inclusion | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-018 · Liquidity planning | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-019 · Adaptation finance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP38-020 · Financial privacy | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-001 · Verification schedule | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-002 · Service delivery | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-003 · Service accounting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-004 · Verification cost | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-005 · Scheme readiness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-006 · Provider eligibility | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-007 · Additionality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-008 · Leakage | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-009 · Permanence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-010 · Contract design | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-011 · Payment proposals | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-012 · Benefit sharing | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-013 · Double counting | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-014 · Monitoring design | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-015 · Funding sustainability | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-016 · Provider safeguards | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-017 · Grievances and appeals | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-018 · Independent review | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-019 · Renewal decisions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP39-020 · Scheme records | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-001 · Dataset selection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-002 · Intervention research | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-003 · Sampling limitations | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-004 · Expert review | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-005 · Research questions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-006 · Ethics and permissions | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-007 · Sampling design | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-008 · Model validation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-009 · Data cleaning | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-010 · Reproducibility | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-011 · Research collaboration | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-012 · Causal interpretation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-013 · Uncertainty priorities | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-014 · Research funding | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-015 · Data publication | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-016 · Longitudinal studies | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-017 · Laboratory quality | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-018 · Knowledge transfer | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-019 · Research outcomes | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP40-020 · Scientific vocabulary | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-001 · Livelihood reach | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-002 · Community feedback | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-003 · Training follow-up | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-004 · Service delays | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-005 · Needs assessment | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-006 · Participation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-007 · Beneficiary selection | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-008 · Support overlap | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-009 · Safeguarding referrals | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-010 · Climate adaptation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-011 · Community assets | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-012 · Volunteer deployment | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-013 · Programme finance | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-014 · Market access | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-015 · Water and sanitation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-016 · Disaster preparedness | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-017 · Programme retention | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-018 · Outcome evaluation | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-019 · Partner coordination | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DEC-DP41-020 · Community evidence | Candidate example under a reusable capability familyProposed candidate; not a contractual deliverable | C01; C02; C04; E01; E02; E03 as applicableAccepted requirement/release,owner,data/source rights,method and local-fit review |
| DP11-PNL02 · Finance and physical progress twin lanes | Finance/procurement content awaits scope confirmation; preserve physical milestones/evidenceProposed; awaiting PMU scope confirmation | C01; C02; C10; C11; C12PMU reconciliation of reviewed scope comments |
Source passages and needs
These short passages and exact locators support the working analysis. Their source class and authority limits remain visible. Consultation records are read-only evidence.
SRC-TOR-DATA · Final ToR-SRS SHARED IS
Source class: Direct terms-of-reference obligation
Locator: page 2, Functional Requirements Definition
Passage: Data integration and management system
Need: Data integration and management is a contractual capability area.
Related requirement IDs: FR029; FR030; FR031; FR032; FR033; FR034; FR035; FR036; FR037; FR038; FR039; FR040; FR041; FR042; FR043; FR044; FR045; FR046; FR047; FR048; FR049; FR050; FR051; FR052; FR053; FR054; FR055; FR056; FR057; FR058; FR059; FR060; FR061; FR062; FR001; FR002; FR003; FR004; FR005; FR006; FR007; FR008; FR009; FR010; FR011; FR012; FR013; FR014; FR015; FR016; FR017; FR018; FR019; FR020; FR021; FR022; FR023; FR024; FR025; FR026; FR027; FR028; FR063; FR064; FR065; FR066; FR067; FR068; FR069; FR070; FR071; FR072; FR073; FR074; FR075; FR076; FR077; FR078; FR079; SH-GEO-FEAT-001; SH-GEO-FEAT-002; SH-GEO-FEAT-003; SH-GEO-FEAT-004; SH-GEO-FEAT-005; SH-GEO-FEAT-006; SH-GEO-FEAT-007; SH-GEO-FEAT-008; SH-GEO-FEAT-009; SH-GEO-FEAT-010; SH-GEO-FEAT-011; SH-GEO-FEAT-012; SH-GEO-FEAT-013; SH-GEO-FEAT-014; SH-GEO-FEAT-015; SH-GEO-FEAT-016; SH-GEO-FEAT-017; SH-GEO-FEAT-018; SH-GEO-FEAT-019; SH-GEO-FEAT-020; FR136; FR137; FR138; FR139; FR140; FR141; FR142; FR143; FR144; FR145; FR146; FR155; FR147; FR148; NFR01; NFR02; NFR03; NFR04; NFR05; NFR06; NFR07; NFR08; NFR09; NFR10; NFR11; NFR12; NFR13; NFR14; FR149; FR151; FR152; FR153; FR154; FR150; FR156
Authority and limits: TOR source authority subject to C01; individual feature/release acceptance not established
SRC-TOR-DSS · Final ToR-SRS SHARED IS
Source class: Direct terms-of-reference obligation
Locator: page 2, Functional Requirements Definition
Passage: Decision Support System (DSS)
Need: Decision support is a contractual capability area.
Related requirement IDs: FR080; FR081; FR094; FR095; FR096; FR097; FR098; FR099; FR100; FR101; FR102; FR103; FR104; FR105; FR106; FR107; FR082; FR083; FR084; FR085; FR092; FR093; FR136; FR137; FR138; FR139; FR140; FR141; FR142; FR143; FR144; FR145; FR146; FR155; FR147; FR148; NFR01; NFR02; NFR03; NFR04; NFR05; NFR06; NFR07; NFR08; NFR09; NFR10; NFR11; NFR12; NFR13; NFR14; FR149; FR151; FR152; FR153; FR154; FR150; FR156
Authority and limits: TOR source authority subject to C01; individual feature/release acceptance not established
SRC-TOR-DASH · Final ToR-SRS SHARED IS
Source class: Direct terms-of-reference obligation
Locator: page 2, Functional Requirements Definition
Passage: Multi-scale dashboards and visualization tools
Need: Dashboards and visualization is a contractual capability area.
Related requirement IDs: FR022; FR023; FR024; FR025; FR026; FR027; FR028; FR063; FR064; FR065; FR066; FR067; FR068; FR069; FR070; FR071; FR072; FR073; FR074; FR075; FR076; FR077; FR078; FR079; SH-GEO-FEAT-001; SH-GEO-FEAT-002; SH-GEO-FEAT-003; SH-GEO-FEAT-004; SH-GEO-FEAT-005; SH-GEO-FEAT-006; SH-GEO-FEAT-007; SH-GEO-FEAT-008; SH-GEO-FEAT-009; SH-GEO-FEAT-010; SH-GEO-FEAT-011; SH-GEO-FEAT-012; SH-GEO-FEAT-013; SH-GEO-FEAT-014; SH-GEO-FEAT-015; SH-GEO-FEAT-016; SH-GEO-FEAT-017; SH-GEO-FEAT-018; SH-GEO-FEAT-019; SH-GEO-FEAT-020; FR094; FR095; FR096; FR097; FR098; FR099; FR100; FR101; FR102; FR103; FR104; FR105; FR106; FR107; FR136; FR137; FR138; FR139; FR140; FR141; FR142; FR143; FR144; FR145; FR146; FR155; FR147; FR148; NFR01; NFR02; NFR03; NFR04; NFR05; NFR06; NFR07; NFR08; NFR09; NFR10; NFR11; NFR12; NFR13; NFR14; FR149; FR151; FR152; FR153; FR154; FR150; FR156
Authority and limits: TOR source authority subject to C01; individual feature/release acceptance not established
SRC-TOR-ME · Final ToR-SRS SHARED IS
Source class: Direct terms-of-reference obligation
Locator: page 2, Functional Requirements Definition
Passage: Monitoring and evaluation (M&E) system
Need: Monitoring and evaluation is a contractual capability area.
Related requirement IDs: FR108; FR109; FR110; FR111; FR112; FR113; FR114; FR115; FR116; FR117; FR118; FR119; FR120; FR121; FR122; FR123; FR124; FR125; FR126; FR127; FR128; FR090; FR091; FR136; FR137; FR138; FR139; FR140; FR141; FR142; FR143; FR144; FR145; FR146; FR155; FR147; FR148; NFR01; NFR02; NFR03; NFR04; NFR05; NFR06; NFR07; NFR08; NFR09; NFR10; NFR11; NFR12; NFR13; NFR14; FR149; FR151; FR152; FR153; FR154; FR150; FR156
Authority and limits: TOR source authority subject to C01; individual feature/release acceptance not established
SRC-TOR-SLM · Final ToR-SRS SHARED IS
Source class: Direct terms-of-reference obligation
Locator: page 2, Functional Requirements Definition
Passage: SLM and PES monitoring and coordination platform
Need: SLM and PES is a contractual capability area.
Related requirement IDs: FR022; FR023; FR024; FR025; FR026; FR027; FR028; FR063; FR064; FR065; FR066; FR067; FR068; FR069; FR070; FR071; FR072; FR073; FR074; FR075; FR076; FR077; FR078; FR079; FR080; FR081; SH-GEO-FEAT-001; SH-GEO-FEAT-002; SH-GEO-FEAT-003; SH-GEO-FEAT-004; SH-GEO-FEAT-005; SH-GEO-FEAT-006; SH-GEO-FEAT-007; SH-GEO-FEAT-008; SH-GEO-FEAT-009; SH-GEO-FEAT-010; SH-GEO-FEAT-011; SH-GEO-FEAT-012; SH-GEO-FEAT-013; SH-GEO-FEAT-014; SH-GEO-FEAT-015; SH-GEO-FEAT-016; SH-GEO-FEAT-017; SH-GEO-FEAT-018; SH-GEO-FEAT-019; SH-GEO-FEAT-020; FR082; FR083; FR084; FR085; FR092; FR093; FR136; FR137; FR138; FR139; FR140; FR141; FR142; FR143; FR144; FR145; FR146; FR155; FR147; FR148; NFR01; NFR02; NFR03; NFR04; NFR05; NFR06; NFR07; NFR08; NFR09; NFR10; NFR11; NFR12; NFR13; NFR14; FR149; FR151; FR152; FR153; FR154; FR150; FR156
Authority and limits: TOR source authority subject to C01; individual feature/release acceptance not established
SRC-TOR-MARKET · Final ToR-SRS SHARED IS
Source class: Direct terms-of-reference obligation
Locator: page 2, Functional Requirements Definition
Passage: Value chain and Market information system
Need: Value chains and markets is a contractual capability area.
Related requirement IDs: FR080; FR081; FR082; FR083; FR084; FR085; FR092; FR093; FR136; FR137; FR138; FR139; FR140; FR141; FR142; FR143; FR144; FR145; FR146; FR155; FR147; FR148; NFR01; NFR02; NFR03; NFR04; NFR05; NFR06; NFR07; NFR08; NFR09; NFR10; NFR11; NFR12; NFR13; NFR14; FR149; FR151; FR152; FR153; FR154; FR150; FR156
Authority and limits: TOR source authority subject to C01; individual feature/release acceptance not established
SRC-TOR-STAKE · Final ToR-SRS SHARED IS
Source class: Direct terms-of-reference obligation
Locator: page 2, Functional Requirements Definition
Passage: Stakeholder interaction interface
Need: Stakeholder interaction is a contractual capability area.
Related requirement IDs: FR001; FR002; FR003; FR004; FR005; FR006; FR007; FR008; FR009; FR010; FR011; FR012; FR013; FR014; FR015; FR016; FR017; FR018; FR019; FR020; FR021; FR108; FR109; FR110; FR111; FR112; FR113; FR114; FR115; FR116; FR117; FR118; FR119; FR120; FR121; FR122; FR123; FR124; FR125; FR126; FR127; FR128; FR090; FR091; FR086; FR087; FR088; FR089; FR129; FR130; FR131; FR132; FR133; FR134; FR135; FR136; FR137; FR138; FR139; FR140; FR141; FR142; FR143; FR144; FR145; FR146; FR155; FR147; FR148; NFR01; NFR02; NFR03; NFR04; NFR05; NFR06; NFR07; NFR08; NFR09; NFR10; NFR11; NFR12; NFR13; NFR14; FR149; FR151; FR152; FR153; FR154; FR150; FR156
Authority and limits: TOR source authority subject to C01; individual feature/release acceptance not established
SRC-TOR-NFR · Final ToR-SRS SHARED IS
Source class: Direct terms-of-reference obligation
Locator: page 2, Non-Functional Requirements
Passage: System performance (response time, uptime ≥ 99%); User accessibility (mobile compatibility, low-bandwidth optimization); Role-based access control
Need: Retain the uptime minimum and mobile-compatible, low-bandwidth access with controlled roles.
Related requirement IDs: NFR01; NFR05; FR009; FR137
Authority and limits: TOR minimum; local test profile and controls still require C05–C08
SRC-TOR-ARCH · Final ToR-SRS SHARED IS
Source class: Direct terms-of-reference obligation
Locator: page 2, System Architecture Design
Passage: Develop high-level and detailed system architecture; Data storage, APIs, and integration protocols
Need: Specify logical architecture and interoperable interfaces without selecting a mandatory product.
Related requirement IDs: FR143; FR144; FR145; FR146; FR147; FR155; NFR11; NFR12
Authority and limits: Documented input; institutional acceptance pending
SRC-TOR-GOV · Final ToR-SRS SHARED IS
Source class: Direct terms-of-reference obligation
Locator: page 2, Data Governance Framework
Passage: Define data types, formats, metadata standards; Develop data governance and sharing protocols; Identify data sources and update frequencies
Need: Specify types, metadata, rights, sources and appropriate refresh cadence.
Related requirement IDs: FR014; FR015; FR016; FR018; FR029; FR030; FR034; FR037; FR038; FR039; FR057; FR058; NFR08
Authority and limits: Documented input; institutional acceptance pending
SRC-TOR-MOCK · Final ToR-SRS SHARED IS
Source class: Direct terms-of-reference obligation
Locator: page 3, Prototyping and Wireframes
Passage: Develop wireframes/mock-ups for key system interfaces; Design role-specific dashboards (policy makers, researchers, farmers); Ensure usability, inclusiveness, and accessibility
Need: Provide useful key mock interfaces, role views and inclusive access.
Related requirement IDs: FR013; FR099; FR134; FR137; FR138; FR142; NFR05; NFR06
Authority and limits: Documented input; institutional acceptance pending
SRC-TOR-ACCEPT · Final ToR-SRS SHARED IS
Source class: Direct terms-of-reference obligation
Locator: page 3, Implementation and Phasing Plan; Performance Metrics and Payment Framework
Passage: Define modules for staged implementation; Identify dependencies and integration priorities; Develop measurable acceptance criteria for deliverables
Need: Keep phased delivery, dependencies and measurable acceptance.
Related requirement IDs: FR150; FR156; NFR14
Authority and limits: Documented input; institutional acceptance pending
SRC-CONS-REPORT · Comments and suggestions
Source class: Documented consultation input
Locator: paragraph 12
Passage: The destination, frequency, required content, format, preparer, and approving authority for each selected report should be collected through a separate follow-up question or table. If the intention is to identify priorities, respondents should be asked to select or rank the three reports that SHARED should support first. Consider adding financial, procurement, safeguards, and annual work-plan reports if they are within the system’s scope.
Need: For each proposed report, confirm destination, frequency, content, format, preparer and approving authority.
Related requirement IDs: FR031; FR094; FR095; FR098; FR100; FR123; FR124; FR125
Authority and limits: Documented input; institutional acceptance pending
SRC-CONS-FREQ · Comments and suggestions
Source class: Documented consultation input
Locator: paragraph 16
Passage: A single answer may not provide an accurate system requirement because the update frequency will vary by information type. It would be better to use a follow-up table asking respondents to select the required update frequency for each main report or data type. “Real-time” should generally apply only where data can be updated automatically through an integrated system; it may not be practical for manually submitted field information. The reference to “user levels” can be removed because access level and update frequency are separate requirements.
Need: Set refresh frequency by information type. Do not describe manual field updates as real-time.
Related requirement IDs: FR029; FR051; FR054; FR056; FR075; FR076; FR123
Authority and limits: Documented input; institutional acceptance pending
SRC-CONS-REUSE · Comments and suggestions
Source class: Documented consultation input
Locator: paragraphs 29–34
Passage: Use data from existing tools while keeping those tools operational Provide links to existing dashboards, maps, and reports Allow data and reports to be imported and exported as files Be designed for future automatic data exchange with other systems (system integration/APIs) Bring separate spreadsheets and trackers together into one central, structured system Unsure—further operational and technical review is required
Need: Consider links, file exchange and approved integration while keeping existing tools operational. Options still need selection.
Related requirement IDs: FR034; FR041; FR045; FR051; FR053; FR056; FR065; FR093; FR143; FR155
Authority and limits: Documented input; institutional acceptance pending
SRC-CONS-SCOPE · Comments and suggestions
Source class: Documented consultation input
Locator: paragraphs 40 and 42
Passage: Q16. Which rules should SHARED apply in Phase 1 to control who can view, enter, change, approve, generate reports from, download, or share information? Permission to generate, view, download, and share reports based on the user’s role and the sensitivity or approval status of the information
Need: Control viewing, entry, changes, approvals, reports, downloads and sharing by role and information sensitivity.
Related requirement IDs: FR002; FR003; FR005; FR007; FR009; FR010; FR036; FR095; FR100; FR120; FR121; FR133; FR149
Authority and limits: Documented input; institutional acceptance pending
SRC-CONS-PUBLIC · Comments and suggestions
Source class: Documented consultation input
Locator: paragraphs 47–56
Passage: Information remains internal unless it is specifically approved for external sharing Information must be classified as public, internal, confidential, or restricted Only approved summaries may be made public; source data and sensitive evidence remain restricted unless separately approved Only approved dashboards, reports, and other outputs may be shared externally External access must be based on the user’s role and organisation Sensitive personal information must not be publicly released and may be accessed only by authorized users Sensitive GIS and location information must be restricted, generalized, or masked before release External sharing must be approved by a named authority and recorded in an audit trail Permission to generate, download, export, or share reports must depend on the user’s role and the information’s classification Restricted information must be removed or masked in externally shared reports
Need: Propose internal-by-default classification, approved public summaries, restricted source evidence, named sharing authority and sensitive-location masking.
Related requirement IDs: FR009; FR010; FR064; FR066; FR095; FR100; FR129; FR130; FR131; FR132; FR133; FR134; FR135; FR149; SH-GEO-FEAT-019; NFR08
Authority and limits: Documented input; institutional acceptance pending
SRC-CONS-COMPONENT · Project correspondence for the inception package
Source class: Documented consultation input
Locator: paragraph 20
Passage: Component 3 work plans and related activity documents (where available). Please note that the SHARED Information System will support all components except Component 3; relevant information is already reflected in the FAA
Need: Resolve the stated exclusion of Component 3 against the controlling programme/release scope before acceptance.
Related requirement IDs: FR108; FR110; FR123; FR150; FR156
Authority and limits: Documented input; institutional acceptance pending
SRC-CONS-TEMPLATES · Project correspondence for the inception package
Source class: Documented consultation input
Locator: paragraph 26
Passage: Where specific reporting templates, evidence templates, data inventories, or related formats are not currently available, the consultancy team is expected to develop draft versions for review and adoption by the project based on the ToR. It should be self content.
Need: Prepare unavailable report, evidence and data templates as drafts for review; do not label them adopted.
Related requirement IDs: FR013; FR014; FR040; FR049; FR101; FR123; FR150
Authority and limits: Documented input; institutional acceptance pending
SRC-CONS-DATA · Project correspondence for the inception package
Source class: Documented consultation input
Locator: paragraph 29
Passage: Currently, only general information is being shared for reference. Any model outputs or additional missing information will be provided upon request or as required during the consultancy process.
Need: Treat supplied GIS material as reference and request missing model outputs or data through owners.
Related requirement IDs: FR023; FR026; FR063; FR069; FR071; FR072; FR073; FR074; FR078; FR079; SH-GEO-FEAT-001; SH-GEO-FEAT-005
Authority and limits: Documented input; institutional acceptance pending
SRC-CONS-COMPLIANCE · Project correspondence for the inception package
Source class: Documented consultation input
Locator: paragraph 104
Passage: Where formal consent forms, privacy notices, consultation protocols, data-sharing agreements, or other compliance-related templates are not available, the consultancy team is expected to prepare draft versions for review and approval by CIFOR-ICRAF and relevant project authorities, ensuring alignment with CIFOR-ICRAF requirements and applicable good practices.
Need: Prepare missing consent, privacy, consultation and sharing templates as drafts for authority review.
Related requirement IDs: FR010; FR037; FR046; FR047; FR129; FR131; FR135; FR149; NFR07; NFR08
Authority and limits: Documented input; institutional acceptance pending
SRC-CONS-OWNER · Project correspondence for the inception package
Source class: Documented consultation input
Locator: paragraphs 108–109
Passage: Hosting expectation: System ownership will remain with the project and be transferred to the appropriate government institution after the project period Future system ownership: To be defined through stakeholder consultation; consultancy team is expected to propose suitable options
Need: Propose custody/transfer and receiving-owner options. Do not treat the eventual government operator as appointed.
Related requirement IDs: FR001; FR003; FR091; FR126; FR127; FR128; FR153; FR154; NFR09; NFR12; NFR14
Authority and limits: Documented input; institutional acceptance pending
SRC-CONS-ACCESS · Project correspondence for the inception package
Source class: Documented consultation input
Locator: paragraph 115
Passage: Dashboards and access control: Public/restricted access, role-based permissions, hosting, and security requirements to be defined through technical consultations
Need: Resolve public/restricted access, hosting and security through technical consultation.
Related requirement IDs: FR004; FR009; FR010; FR066; FR131; FR134; FR146; FR155; NFR07; NFR08; NFR14
Authority and limits: Documented input; institutional acceptance pending
SRC-CONS-HANDOVER · Project correspondence for the inception package
Source class: Documented consultation input
Locator: paragraph 9
Passage: Submission Format: MS Word and PDF. Presentations are required prior to final submission. All final deliverables, including collected raw, processed, and final datasets, are to be submitted via hard drive.
Need: Retain editable and read-only final document formats, validation presentation and accepted final dataset handover.
Related requirement IDs: FR142; FR150; FR156; NFR12; NFR14
Authority and limits: Documented input; institutional acceptance pending
SRC-PMU-EXCLUSION · PMU Meeting 2 reviewed comments
Source class: Documented consultation input
Locator: Word comments 1–3: financial progress paragraph 29; oversight paragraph 39; internal management paragraph 93
Passage: Financial progress and budget-use summaries: Not relevant to SHARED IS. Internal management summaries: Not relevant.
Need: Proposed PMU finance/procurement examples need a scope decision; preserve physical milestones and evidence.
Related requirement IDs: FR110; FR123; FR150; FR156
Authority and limits: Documented scope comment; reconciliation pending C01/C02/C10/C11/C12
Correction addendum and actual test evidence
Connected data architecture
Architecture extension A1 links the existing requirement IDs to components, contracts, diagrams, synthetic demonstrations and executed local checks. It does not execute the institutional acceptance plans or add approval topics.
Architecture explorer and demonstrations · Architecture traceability · Device and API sources