guide-board/workplans/GUIDE-BOARD-WP-0004-source-lock-and-submission-package-baseline.md

id, type, title, repo, domain, status, owner, planning_priority, planning_order, created, updated, state_hub_workstream_id

id	type	title	repo	domain	status	owner	planning_priority	planning_order	created	updated	state_hub_workstream_id
GUIDE-BOARD-WP-0004	workplan	Source Lock And Submission Package Baseline	guide-board	markitect	active	codex	high	4	2026-05-15	2026-05-15	6dd2832b-d1d9-43bc-ad5c-d16f399930dc

GUIDE-BOARD-WP-0004: Source Lock And Submission Package Baseline

Purpose

Make guide-board assessment packages source-complete enough for serious review. Runs already snapshot target and assessment profiles and preserve normalized evidence. The next maturity layer is a stronger source lock and a submission package manifest that records which framework, extension, harness, mapping, profile, waiver, and artifact sources produced the assessment.

Background

The architecture blueprint calls out source locking as part of credible assessment evidence. A reviewer should be able to distinguish a normal local run from a package that is ready to hand to another team, auditor, authority, or certification-preparation process. This does not turn guide-board into a certification body; it makes the evidence boundary clearer and more portable.

Boundary

This workplan owns extension-neutral source lock fields and package manifest generation. Extension-specific harness version detection, authority-specific submission rules, and licensed or restricted assets remain extension-owned.

D4.1 - Source Lock Schema And Capture

id: GUIDE-BOARD-WP-0004-T001
status: todo
priority: high
state_hub_task_id: "d5a7a18f-941b-47b8-9992-2cb54bc5ad06"

Acceptance:

• Extend the source lock contract beyond framework and extension IDs.
• Capture stable references for framework versions, extension versions, mapping sets, target profile snapshots, assessment profile snapshots, expectation sets, waiver sets, and authority source URLs when available.
• Keep the schema backward-compatible with existing retained runs.
• Add tests for source lock shape and retained run compatibility.

D4.2 - Harness And Extension Metadata Hooks

id: GUIDE-BOARD-WP-0004-T002
status: todo
priority: high
state_hub_task_id: "7abd5a66-5784-41b9-a361-6572290923cc"

Acceptance:

• Define how extensions and runner or normalizer results can report harness versions, test suite IDs, adapter versions, source URLs, and native result identifiers.
• Persist this metadata in run plans, evidence facts, source locks, or package manifests without inventing domain-specific fields in the core.
• Preserve current runner and normalizer contracts for extensions that do not provide this metadata yet.
• Cover the SDK fixture and at least one no-metadata extension path in tests.

D4.3 - Submission Package Manifest

id: GUIDE-BOARD-WP-0004-T003
status: todo
priority: medium
state_hub_task_id: "c54273d6-1fc2-4444-92cf-74f2a5e614ec"

Acceptance:

• Add a machine-readable submission package manifest under each run report directory.
• Include package identity, source lock references, report paths, normalized evidence paths, artifact manifest entries, checksums where available, and the certification boundary.
• Keep the manifest useful for both executable harnesses and procedural evidence packs.
• Document how this differs from an authority-specific final submission.

D4.4 - Documentation And Acceptance Tests

id: GUIDE-BOARD-WP-0004-T004
status: todo
priority: medium
state_hub_task_id: "ad37baeb-973c-4399-96d0-c9cb7fc6b761"

Acceptance:

• Update assessment operations, extension SDK, and architecture docs with the source lock and submission package contracts.
• Add tests that run a sample or SDK fixture assessment and assert the source lock and manifest outputs.
• Include compatibility notes for older retained runs.
• Keep the output paths aligned with existing CLI and service result retrieval.

Definition Of Done

• Every new run writes a richer source lock and submission package manifest.
• Extension-provided harness metadata has a stable path into the package.
• Older retained runs remain readable.
• Operators and extension authors know what the package can and cannot claim.