docs: restructure README and add harness-eval references

Docs/ADR_Skill_Evaluation_Pipeline_and_Harbor_Execution_Strategy.txt

@@ -10,7 +10,7 @@ The objective is to establish an automated pipeline for evaluating skill submiss
 
 2. Architectural Details (Skill Evaluation Pipeline Workflow)
 The pipeline is an 8-step process orchestrated by Tekton.
-Step 1 — Submission
+Step 1 -- Submission
 * Trigger: Git + Tekton EventListener. A user pushes a skill directory to a branch in a dedicated repository (e.g., skill-eval-submissions).
 * Submission Contract: The directory follows this structure:
 my-skill-name/
@@ -23,7 +23,7 @@ Step 1 — Submission
 ├── supportive/       # optional: mock MCPs, data files
 └── metadata.yaml     # user-provided: description, persona, etc.
 * Tools: GitHub, Tekton Triggers (EventListener + TriggerTemplate), and Tekton Interceptors (to filter on pushes to submissions/ path).
-Step 2 — Validation (Tekton Task)
+Step 2 -- Validation (Tekton Task)
 
 
 A container runs validation checks on the submitted files:
@@ -33,21 +33,21 @@ A container runs validation checks on the submitted files:
 * Validate metadata.yaml schema (pydantic or jsonschema).
 * Check supportive files are a reasonable size (<50MB total).
 * Tools: Custom Tekton Task with a Python image, using ubi9/python-311 as the base image.
-Step 3 — Scaffold (Tekton Task)
+Step 3 -- Scaffold (Tekton Task)
 
 
 Generates the files the user shouldn't have to write, including a templated Dockerfile (based on supportive files) and creating needed files like test.sh and task.toml.
 * Variants Created:
    * A skilled variant (tasks/my-skill-name/) with the Dockerfile configured to COPY skills, docs.
    * An unskilled variant (tasks-no-skills/my-skill-name/) with a Dockerfile that excludes skills/docs but includes supportive infra.
 * Tools: Custom Tekton Task with Python/Jinja2 for templating. Store Dockerfile/test.sh templates in a ConfigMap or in the pipeline repo.
-Step 4 & 5 — Build & Push Images (Tekton Tasks)
+Step 4 & 5 -- Build & Push Images (Tekton Tasks)
 
 
 Build both the skilled and unskilled container images and push them to a registry.
 * Tools: docker buildx or Buildah.
 * Registry Options: Quay.io.
-Step 6 — Run Harbor Evaluation (Tekton Task)
+Step 6 -- Run Harbor Evaluation (Tekton Task)
 
 
 This is the core evaluation step. Harbor must run N attempts per variant (skilled + unskilled), where each attempt spins up a container from the pre-built image, runs the agent and the verifier inside it, and aggregates results. There are two viable approaches for how Harbor executes these trials on OpenShift.
@@ -61,9 +61,9 @@ Approach
 	Requires privileged access or nested containers to function; introduces security concerns.
 	OpenShift Backend for Harbor
 	Harbor uses the Kubernetes API to create, manage, and clean up lightweight, unprivileged Pods for each trial, replacing Google-specific calls[c][d].
-	Creates lightweight, regular Pods—no nesting, no privileges; standard RBAC; OpenShift can see, schedule, and resource-limit each trial Pod independently; trial Pod logs are visible in the OpenShift Console like any other workload.
+	Creates lightweight, regular Pods--no nesting, no privileges; standard RBAC; OpenShift can see, schedule, and resource-limit each trial Pod independently; trial Pod logs are visible in the OpenShift Console like any other workload.
 	Requires writing one new file in Harbor (the OpenShift environment backend) to replace the three Google-specific functions.
-	Step 7 — Analyze & Report (Tekton Task)
+	Step 7 -- Analyze & Report (Tekton Task)
 
 
 Runs existing analysis and plot scripts to generate a summary report (markdown or HTML) that includes:
@@ -72,7 +72,7 @@ Runs existing analysis and plot scripts to generate a summary report (markdown o
 * Statistical significance (p-value).
 * Heatmap figures embedded.
 * Links to detailed logs.
-Step 8 — Publish & Store (Tekton Task)
+Step 8 -- Publish & Store (Tekton Task)
 
 
 Finalizes the publishing and storage of evaluation results.
@@ -92,7 +92,7 @@ The consequences and required dependencies depend on the chosen approach:
       * Cons: Requires privileged access or nested containers to function; introduces security concerns.
       * Dependencies: Podman, OpenShift Secrets for credentials/volume mounting.
    * If adopting "OpenShift Backend for Harbor":
-      * Pros: Creates lightweight, regular Pods—no nesting, no privileges; utilizes standard RBAC; individual trial Pods are fully visible, schedulable, and resource-limited by OpenShift.
+      * Pros: Creates lightweight, regular Pods--no nesting, no privileges; utilizes standard RBAC; individual trial Pods are fully visible, schedulable, and resource-limited by OpenShift.
       * Cons: Requires writing one new file in Harbor (the OpenShift environment backend) to replace three Google-specific functions.
       * Dependencies: Custom Harbor Backend implementation (a new file).
 4. Operational and Security Considerations
@@ -119,7 +119,7 @@ The consequences and required dependencies depend on the chosen approach:
 Notes and Comments
 Following the ADR meeting, here is a concise summary of the Tessl investigation:
 * Harbor (The Local Tool): Harbor is an open-source CLI that lets you run and evaluate agents locally using Podman containers and "behind the scenes" Tessl and Harbor run the same backend (by Tessl).
-* Tessl Cloud (The Automated Tool): This cloud service creates test scenarios and runs your agent twice—once as a baseline and once with context—to show you the performance difference (the "delta") as with Harbor.
+* Tessl Cloud (The Automated Tool): This cloud service creates test scenarios and runs your agent twice--once as a baseline and once with context--to show you the performance difference (the "delta") as with Harbor.
 * No Local Tessl: There is no local version of Tessl, it functions as a cloud wrapper where the CLI handles the connection, but the server does all the work.
 * Infrastructure Limits: You cannot self-host Tessl or use your own cloud infrastructure for these runs.
 * Model Restrictions: The platform currently only supports Claude models (via api key so it rules out as i understand the vertex solution we use) and does not allow you to bring outside models like Qwen.
@@ -145,9 +145,9 @@ continuous performance monitoring
 
 
 From the Harbor GKE backend : 
-_init_client — authenticates to the cluster using gcloud
-_build_and_push_image — builds and pushes the container image using gcloud
-_image_exists — checks if the image already exists in the registry using gcloud
+_init_client -- authenticates to the cluster using gcloud
+_build_and_push_image -- builds and pushes the container image using gcloud
+_image_exists -- checks if the image already exists in the registry using gcloud
 
 
 Everything else from what i saw is ok and no need to fix.

Docs/SOTA_demands.md

@@ -1,14 +1,14 @@
 # SOTA Demands: CI and Monitoring Pipeline
 
-Assessment of ABEvalFlow's CI (`abevalflow-pipeline`) and monitoring (`abevalflow-monitoring-pipeline`) against state-of-the-art expectations for agent, tool, skill, and MCP evaluation platforms.
+Assessment of Agentic Eval Flow's CI (`abevalflow-pipeline`) and monitoring (`abevalflow-monitoring-pipeline`) against state-of-the-art expectations for agent, tool, skill, and MCP evaluation platforms.
 
 **Scope:** Gap analysis and recommended roadmap. Does not replace existing ADRs or implementation plans.
 
 ---
 
 ## Executive Summary
 
-ABEvalFlow is **SOTA on breadth**: multi-engine evaluation (Harbor, ASE, MCPChecker, A2A) on OpenShift with persistence, statistical A/B analysis, and a separate monitoring path.
+Agentic Eval Flow is **SOTA on breadth**: multi-engine evaluation (Harbor, ASE, MCPChecker, A2A) on OpenShift with persistence, statistical A/B analysis, and a separate monitoring path.
 
 It is **not yet SOTA on enforcement, observability depth, or lifecycle closure**:
 
@@ -92,9 +92,9 @@ This combination is ahead of most approaches that only lint or unit-test skill f
 | **Test phase** | Skipped in monitoring pipeline (no security re-scan on canary runs) |
 | **Degradation logic** | Last-run vs previous-run ratio (`monitor.py`, default 0.85) |
 | **Statistics** | No CUSUM, rolling baseline, or seasonality (noted as post-MVP in APPENG-4911) |
-| **Schedule** | Cron every 10 days — coarse |
+| **Schedule** | Cron every 10 days -- coarse |
 | **Triggers** | No webhook on model upgrade, prompt change, or agent deploy |
-| **Canary config** | ConfigMap — not a versioned baseline registry or dedicated canary repo |
+| **Canary config** | ConfigMap -- not a versioned baseline registry or dedicated canary repo |
 | **CI linkage** | CI has `enable-degradation-check: false`; monitoring and CI use disconnected policies |
 
 **SOTA expectation:** Event-driven canaries (model/prompt/infra change) + statistical process control + fleet dashboards + auto-ticket on regression.
@@ -105,16 +105,16 @@ This combination is ahead of most approaches that only lint or unit-test skill f
 
 | Gap | Detail |
 |-----|--------|
-| **Static security only** | Cisco scan on skill content — no dynamic red-team or adversarial eval during agent runs |
+| **Static security only** | Cisco scan on skill content -- no dynamic red-team or adversarial eval during agent runs |
 | **No skills quality linter in CI** | skillsaw-style structural lint not integrated |
 | **Snyk / dependency scan** | Designed (APPENG-5305) but not wired like Cisco in the current test phase |
 | **Single model per run** | No matrix (model × agent × engine) |
 | **Flake handling** | No pass@k reporting, retry-aware stats, or infra-error exclusion in marketplace gate |
 | **Multi-task benchmarks** | One submission ≈ one task; no curated benchmark suite execution |
 | **MCPChecker bypasses test phase** | MCP submissions skip security and quality gates |
-| **A2A pass criteria** | Heuristic threshold — not comparable to Harbor A/B semantics |
+| **A2A pass criteria** | Heuristic threshold -- not comparable to Harbor A/B semantics |
 
-**SOTA expectation:** Layered eval — lint → static security → functional eval → adversarial probe → monitoring canary.
+**SOTA expectation:** Layered eval -- lint → static security → functional eval → adversarial probe → monitoring canary.
 
 ---
 
@@ -145,28 +145,28 @@ The pipeline narrative includes GEPA, SkillOps, and skillberry-style authoring,
 
 ## Recommended Roadmap
 
-### P0 — Marketplace Trust (3–6 weeks)
+### P0 -- Marketplace Trust (3–6 weeks)
 
-1. **Enforced gate matrix** — Skip `evaluate` when `tests-passed=false`. Add `marketplace-mode` with stricter thresholds (uplift + p-value + security block).
-2. **GitHub commit status / required check** — Not only PR comments.
-3. ✅ **Unified scorecard schema** — `scorecard.json` with `gates[]` breakdown combining engine, security, and quality gates. Configurable via `gate_policy` in `metadata.yaml`. *(Implemented 2026-06-16)*
-4. ✅ **Quality review blocking mode** — Gates support `disabled`, `warn`, or `block` modes. *(Implemented 2026-06-16)*
+1. **Enforced gate matrix** -- Skip `evaluate` when `tests-passed=false`. Add `marketplace-mode` with stricter thresholds (uplift + p-value + security block).
+2. **GitHub commit status / required check** -- Not only PR comments.
+3. ✅ **Unified scorecard schema** -- `scorecard.json` with `gates[]` breakdown combining engine, security, and quality gates. Configurable via `gate_policy` in `metadata.yaml`. *(Implemented 2026-06-16)*
+4. ✅ **Quality review blocking mode** -- Gates support `disabled`, `warn`, or `block` modes. *(Implemented 2026-06-16)*
 
-### P1 — Observability and Monitoring (6–10 weeks)
+### P1 -- Observability and Monitoring (6–10 weeks)
 
 5. **Grafana dashboards** on PostgreSQL (pass rate, uplift, p-value, degradation, cost).
 6. **Token and time tracking** per run and per trial.
-7. **Monitoring v2** — Rolling baseline, CUSUM, triggers on model/prompt/agent change, Jira or Slack ticket on regression.
-8. **MLflow or Langfuse observer** — Implement at least one observer behind `ResultsObserver`.
+7. **Monitoring v2** -- Rolling baseline, CUSUM, triggers on model/prompt/agent change, Jira or Slack ticket on regression.
+8. **MLflow or Langfuse observer** -- Implement at least one observer behind `ResultsObserver`.
 
-### P2 — SOTA Eval Depth (ongoing)
+### P2 -- SOTA Eval Depth (ongoing)
 
-9. **ODH `eval.yaml` engine adapter** — Shared contract without replacing the Tekton shell.
-10. **Benchmark registry** — Versioned datasets (skills, MCP tasks, agent scenarios), not only ad hoc submissions.
+9. **ODH `eval.yaml` engine adapter** -- Shared contract without replacing the Tekton shell.
+10. **Benchmark registry** -- Versioned datasets (skills, MCP tasks, agent scenarios), not only ad hoc submissions.
 11. **skillsaw + Snyk** in test phase alongside Cisco.
-12. **Adversarial eval pack** — Runtime prompt-injection probes, not only static scan.
-13. **Multi-model matrix** — Optional PipelineRun matrix parameter.
-14. **skillberry / GEPA hook** — Optional post-fail optimization pipeline branch.
+12. **Adversarial eval pack** -- Runtime prompt-injection probes, not only static scan.
+13. **Multi-model matrix** -- Optional PipelineRun matrix parameter.
+14. **skillberry / GEPA hook** -- Optional post-fail optimization pipeline branch.
 
 ---
 
@@ -188,10 +188,10 @@ The pipeline narrative includes GEPA, SkillOps, and skillberry-style authoring,
 
 ## Related Documentation
 
-- [implementation_plan.md](implementation_plan.md) — Phased pipeline build-out
-- [results_persistence_and_observability_plan.md](results_persistence_and_observability_plan.md) — DB, observers, Grafana follow-ups
-- [trigger_models_and_experiment_types.md](trigger_models_and_experiment_types.md) — PR vs submissions-repo models
-- [failure_handling.md](failure_handling.md) — Pipeline failure behavior
+- [implementation_plan.md](implementation_plan.md) -- Phased pipeline build-out
+- [results_persistence_and_observability_plan.md](results_persistence_and_observability_plan.md) -- DB, observers, Grafana follow-ups
+- [trigger_models_and_experiment_types.md](trigger_models_and_experiment_types.md) -- PR vs submissions-repo models
+- [failure_handling.md](failure_handling.md) -- Pipeline failure behavior
 
 ---
 

Docs/certification_and_checks.md

@@ -1,6 +1,6 @@
 # Certification, Scorecards, Checks, and Facts
 
-This document describes ABEvalFlow's certification system, which evaluates AI artifacts (skills, MCP servers, agents) against a comprehensive set of checks organized into three certification levels.
+This document describes Agentic Eval Flow's certification system, which evaluates AI artifacts (skills, MCP servers, agents) against a comprehensive set of checks organized into three certification levels.
 
 ## Overview
 
@@ -118,9 +118,9 @@ certification_policy:
 
 ### Priority Order
 
-1. **Submission's `metadata.yaml`** — if `certification_policy` is present, use it
-2. **Pipeline's `--certification-profile`** — if set, load profile from config
-3. **Hardcoded defaults** — fallback to `FOUNDATIONAL_CHECKS`, `TRUSTED_CHECKS`, `CERTIFIED_CHECKS` in Python
+1. **Submission's `metadata.yaml`** -- if `certification_policy` is present, use it
+2. **Pipeline's `--certification-profile`** -- if set, load profile from config
+3. **Hardcoded defaults** -- fallback to `FOUNDATIONAL_CHECKS`, `TRUSTED_CHECKS`, `CERTIFIED_CHECKS` in Python
 
 ### Code Location
 
@@ -688,9 +688,9 @@ profiles:
 | Change fact payload structure | `compass_facts.py` |
 
 **No changes needed in:**
-- `compass_facts.py` — automatically picks up new checks
-- `scorecard.py` — automatically includes new checks  
-- Pipeline YAML — just select the profile
+- `compass_facts.py` -- automatically picks up new checks
+- `scorecard.py` -- automatically includes new checks  
+- Pipeline YAML -- just select the profile
 
 ---
 

Docs/compass_facts_integration.md

@@ -1,11 +1,11 @@
 # Compass Facts API Integration
 
-ABEvalFlow can push gate evaluation results to Red Hat Compass as Soundcheck facts.
+Agentic Eval Flow can push gate evaluation results to Red Hat Compass as Soundcheck facts.
 This enables visibility of skill evaluation metrics directly in the Compass developer portal.
 
 ## Overview
 
-When configured, ABEvalFlow will POST gate results to the Compass Facts API after each
+When configured, Agentic Eval Flow will POST gate results to the Compass Facts API after each
 gate evaluation completes. This provides real-time visibility into:
 
 - Engine gate results (Harbor, ASE, A2A, MCPChecker)
@@ -110,7 +110,7 @@ Each gate result is pushed as a Soundcheck fact with this structure:
 
 ## Certification Levels
 
-ABEvalFlow automatically computes certification levels based on gate results and pushes
+Agentic Eval Flow automatically computes certification levels based on gate results and pushes
 them to Compass. Three certification levels are supported:
 
 | Level | Description | Requirements |
@@ -121,7 +121,7 @@ them to Compass. Three certification levels are supported:
 
 ### Certification Facts
 
-When `push_facts` is configured, ABEvalFlow automatically pushes 4 certification facts:
+When `push_facts` is configured, Agentic Eval Flow automatically pushes 4 certification facts:
 
 | Fact Reference | Description |
 |----------------|-------------|
@@ -299,7 +299,7 @@ will raise a `ValueError` at runtime.
 ## Validation Warning
 
 If `push_facts.endpoint` is configured but no gates have `push_fact: true`,
-ABEvalFlow logs a warning:
+Agentic Eval Flow logs a warning:
 
 ```
 WARNING: push_facts.endpoint is configured but no gates have push_fact=True.
@@ -429,7 +429,7 @@ kubectl run dns-test --rm -it --restart=Never --image=busybox -- nslookup compas
 
 ## Error Handling
 
-- If a fact push fails, ABEvalFlow logs a warning but continues processing
+- If a fact push fails, Agentic Eval Flow logs a warning but continues processing
 - Gate evaluation results are not affected by fact push failures
 - Timeouts default to 30 seconds per push request
 - Authentication failures (401/403) are logged with the specific error