http service with health, extension listing, profile validation, run planning, async run jobs, job inspection, and report retrieval

docs/ARCHITECTURE-BLUEPRINT.md

@@ -301,6 +301,15 @@ cluster, product, API, data archive, host, organization, process, or policy set.
 Assessment profiles select frameworks, controls, check groups, expectations,
 waivers, output policies, and retention policies.
 
+### Local Service Facade
+
+Wraps the CLI/core contracts in a dependency-light local HTTP API. The service
+can list extensions, validate profiles, build plans, start assessment jobs,
+inspect job status, and fetch generated reports.
+
+The first implementation stores job status in memory and leaves durable evidence
+in the normal run directory. It does not introduce separate execution semantics.
+
 ### Assessment Planner
 
 Resolves an assessment profile into an executable run plan:
@@ -446,6 +455,11 @@ executable harness exists.
 
 Examples: GDPR, SOC 2, HIPAA, NF Z 42-013, NF 461, ISO 14641, ISO 15489.
 
+Procedural packs use evidence request sets to describe artifact collection,
+review roles, acceptance criteria, confidentiality, renewal expectations, and
+waiver paths without reproducing restricted standard text. See
+`docs/COMPLIANCE-EVIDENCE-PACKS.md`.
+
 ### Hybrid Extension
 
 Combines automated checks, manual evidence, external auditor review, and imported

docs/COMPLIANCE-EVIDENCE-PACKS.md

@@ -0,0 +1,141 @@
+# Compliance Evidence Pack Strategy
+
+Status: draft
+Created: 2026-05-07
+
+## Purpose
+
+Compliance evidence packs cover frameworks where guide-board cannot rely on an
+official executable harness. They help prepare and perform assessments by
+organizing evidence requests, expected artifacts, reviewer workflow, waivers,
+and run reports. They do not replace auditors, accredited certification bodies,
+legal counsel, or official standard text.
+
+Examples include GDPR, SOC 2, HIPAA, NF Z 42-013, NF 461, ISO 14641, ISO 15489,
+and similar procedural or control-oriented frameworks.
+
+## Core Boundary
+
+Guide-board should keep four layers separate:
+
+- Official source metadata: authority, framework version, source URL, access
+  constraints, and citation references.
+- Internal interpretation: locally authored control themes, evidence request
+  wording, review roles, and acceptance criteria.
+- Target evidence: artifacts, attestations, screenshots, logs, policy files,
+  architecture documents, operational records, and interview notes.
+- Assessment result: normalized evidence, findings, waivers, trend summaries,
+  and quality gates.
+
+The core may store references to official clauses, controls, or articles, but it
+must not redistribute proprietary standard text. Extension authors are
+responsible for confirming source licensing and citation posture.
+
+## Extension Shape
+
+Compliance packs are ordinary extensions with `extension_type` set to
+`procedural_evidence` or `hybrid`.
+
+Recommended extension layout:
+
+```text
+<extension-id>/
+  INTENT.md
+  extension.json
+  evidence-requests/
+    <request-set-id>.json
+  mappings/
+    <mapping-set-id>.json
+  profiles/
+  reports/
+  workplans/
+```
+
+The manifest should declare:
+
+- framework IDs in `supported_frameworks`,
+- authority IDs in `authorities`,
+- manual or procedural `check_groups`,
+- mapping sets that map request requirement refs to controls or assessment
+  themes,
+- a certification boundary that states the pack is preparation support only.
+
+## Evidence Request Sets
+
+An evidence request set is a reviewable catalog of questions and artifacts. It
+validates against:
+
+```text
+docs/schemas/evidence-request-set.schema.json
+```
+
+Each request should include:
+
+- stable request ID,
+- requirement refs or internal control refs,
+- request type, such as document, interview, configuration sample, operational
+  record, attestation, system export, or mixed evidence,
+- requested artifact classes,
+- reviewer roles,
+- acceptance criteria,
+- confidentiality level,
+- renewal or freshness expectations.
+
+Requests should be phrased as collection guidance, not as legal conclusions.
+
+## Waivers And Expected Gaps
+
+Evidence packs use the same expectation and waiver model as executable
+extensions.
+
+Use expectations for:
+
+- not-applicable scope boundaries,
+- unsupported-by-design target posture,
+- evidence that is intentionally deferred until a later assessment phase.
+
+Use waivers for:
+
+- approved exceptions,
+- compensating-control situations,
+- temporary missing evidence,
+- auditor-reviewed deviations.
+
+Every waiver should include owner, reason, approval status, and expiry.
+
+## Framework Notes
+
+GDPR packs should emphasize processing inventory, lawful basis records, data
+subject rights, subprocessors, transfer posture, breach response, and privacy
+governance without providing legal advice.
+
+SOC 2 packs should organize evidence by trust-service criteria references,
+control ownership, system boundaries, change management, security operations,
+vendor management, and incident response.
+
+HIPAA packs should separate administrative, physical, and technical safeguard
+evidence from policy interpretation and should clearly mark protected-health
+information handling constraints.
+
+NF Z 42-013, NF 461, ISO 14641, and ISO 15489 packs should focus on records
+management, archival integrity, traceability, retention, reversibility,
+auditability, and governance evidence. Proprietary standard text should be
+referenced only by stable IDs or user-provided licensed material.
+
+## Output Model
+
+Compliance packs should produce the same guide-board outputs as harness
+extensions:
+
+- normalized evidence,
+- findings,
+- mapping records,
+- assessment packages,
+- retention summaries,
+- trend summaries,
+- gate summaries.
+
+Manual requests can initially result in `manual`, `blocked`, `not_applicable`,
+or `expected_gap` evidence. Later pack-specific runners may import spreadsheets,
+document inventories, ticket exports, cloud configuration snapshots, or auditor
+review files and normalize them into the same evidence model.

docs/CONTAINER.md

@@ -102,14 +102,17 @@ preflight runner, command wrapper, and mappings. It does not include the final
 Apache Chemistry TCK dependency graph. A future CMIS image should add Java/Maven
 and document how the OpenCMIS TCK artifacts are resolved or mounted.
 
-## Service Path
+## Service Mode
 
-A service image should call the same CLI contracts used here:
+The current core image can run the local service API through the same entrypoint:
 
-- validate profiles,
-- build run plans,
-- execute runs,
-- read run metadata, evidence, reports, retention summaries, trends, and gates.
+```sh
+podman run --rm -p 8080:8080 \
+  -v "$PWD/runs:/runs" \
+  guide-board-core:local \
+  --root /opt/guide-board serve --host 0.0.0.0 --port 8080
+```
 
-The service layer may add job tracking and HTTP transport, but it should not
-create separate execution semantics.
+The service layer adds in-memory job tracking and HTTP transport. Execution
+semantics remain the CLI/core semantics documented in
+`docs/LOCAL-SERVICE-API.md`.

docs/EXTENSION-SDK.md

@@ -21,6 +21,7 @@ extensions/<extension-id>/
   src/
   docs/
   schemas/
+  evidence-requests/
   checks/
   mappings/
   profiles/
@@ -157,6 +158,32 @@ to extension-owned mappings and writes normalized mapping records to:
 runs/<run-id>/normalized/mappings.json
 ```
 
+## Evidence Request Sets
+
+Procedural and hybrid compliance extensions may include evidence request sets
+under:
+
+```text
+evidence-requests/<request-set-id>.json
+```
+
+These files validate against:
+
+```text
+docs/schemas/evidence-request-set.schema.json
+```
+
+Evidence request sets are for collection guidance and review workflow. They
+should reference official requirements by stable IDs or user-held licensed
+material, but they must not redistribute proprietary standard text. A starter
+template lives at:
+
+```text
+extensions/_template/evidence-request-set.json
+```
+
+See `docs/COMPLIANCE-EVIDENCE-PACKS.md` for the compliance-pack strategy.
+
 ## Expectations And Waivers
 
 Assessment profiles may reference expectation and waiver sets:

docs/LOCAL-SERVICE-API.md

@@ -0,0 +1,114 @@
+# Guide Board Local Service API
+
+Status: draft
+Created: 2026-05-07
+
+## Purpose
+
+The local service API is a thin HTTP facade over the same discovery, validation,
+planning, execution, and report contracts used by the CLI. It is intended for
+local development, containerized operation, and future UI integration.
+
+It does not change certification boundaries: guide-board prepares structured
+evidence and assessment packages, but it does not issue certifications or audit
+assurance.
+
+## Start
+
+```sh
+PYTHONPATH=src python3 -m guide_board serve --host 127.0.0.1 --port 8080
+```
+
+External extension repositories use the same top-level option as the CLI:
+
+```sh
+PYTHONPATH=src python3 -m guide_board \
+  --extension-dir ../open-cmis-tck \
+  serve --host 127.0.0.1 --port 8080
+```
+
+Paths supplied to request bodies are resolved relative to the configured
+`--root` unless they are absolute paths.
+
+## Endpoints
+
+### `GET /health`
+
+Returns service status, configured root, and in-memory job counts.
+
+### `GET /extensions`
+
+Lists bundled and configured external extensions using the same discovery logic
+as `guide-board extensions list`.
+
+### `POST /profiles/validate`
+
+Validates a target or assessment profile.
+
+```json
+{
+  "kind": "target",
+  "path": "profiles/targets/sample-repository.json"
+}
+```
+
+Use `"kind": "assessment"` for assessment profiles.
+
+### `POST /assessments/plan`
+
+Builds a run plan without starting a run.
+
+```json
+{
+  "target": "profiles/targets/sample-repository.json",
+  "assessment": "profiles/assessments/sample-noop.json"
+}
+```
+
+An optional `extension_dirs` array can add request-specific external extension
+locations.
+
+### `POST /runs`
+
+Starts an assessment run in a background thread and returns a job record.
+
+```json
+{
+  "target": "profiles/targets/sample-repository.json",
+  "assessment": "profiles/assessments/sample-noop.json",
+  "output_dir": "runs/sample-noop"
+}
+```
+
+The HTTP job status is `queued`, `running`, `succeeded`, or `failed`. A
+`succeeded` job means the guide-board executor completed and wrote its normal
+run directory; the assessment result itself is still reported separately as
+`completed`, `failed`, `blocked`, or `infrastructure_error`.
+
+### `GET /runs`
+
+Lists known in-memory jobs for the current service process.
+
+### `GET /runs/{job_id}`
+
+Returns a single job record with request metadata, result paths, or execution
+errors.
+
+### `GET /runs/{job_id}/reports`
+
+Returns the Markdown report content, assessment package JSON, retention summary,
+and their filesystem paths after a job has succeeded.
+
+## Container Mode
+
+The core container can run the service through the existing entrypoint:
+
+```sh
+podman run --rm -p 8080:8080 \
+  -v "$PWD/runs:/runs" \
+  guide-board-core:local \
+  --root /opt/guide-board serve --host 0.0.0.0 --port 8080
+```
+
+The service keeps job state in memory. Durable run evidence remains in the
+mounted output directory.

docs/schemas/evidence-request-set.schema.json

@@ -0,0 +1,65 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Guide Board Evidence Request Set",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "id",
+    "extension_id",
+    "framework_refs",
+    "source_boundary",
+    "evidence_requests"
+  ],
+  "properties": {
+    "id": { "type": "string" },
+    "extension_id": { "type": "string" },
+    "framework_refs": { "type": "array", "items": { "type": "string" } },
+    "source_boundary": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "official_sources",
+        "interpretation_owner",
+        "redistribution_policy",
+        "certification_boundary"
+      ],
+      "properties": {
+        "official_sources": { "type": "array", "items": { "type": "string" } },
+        "interpretation_owner": { "type": "string" },
+        "redistribution_policy": { "type": "string" },
+        "certification_boundary": { "type": "string" }
+      }
+    },
+    "evidence_requests": {
+      "type": "array",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": [
+          "id",
+          "title",
+          "requirement_refs",
+          "request_type",
+          "description",
+          "requested_artifacts",
+          "review_roles",
+          "acceptance_criteria",
+          "confidentiality",
+          "renewal"
+        ],
+        "properties": {
+          "id": { "type": "string" },
+          "title": { "type": "string" },
+          "requirement_refs": { "type": "array", "items": { "type": "string" } },
+          "request_type": { "type": "string" },
+          "description": { "type": "string" },
+          "requested_artifacts": { "type": "array", "items": { "type": "string" } },
+          "review_roles": { "type": "array", "items": { "type": "string" } },
+          "acceptance_criteria": { "type": "array", "items": { "type": "string" } },
+          "confidentiality": { "type": "string" },
+          "renewal": { "type": "object" }
+        }
+      }
+    }
+  }
+}