nsaspy/prolog-rlm

Fork 0

[EPIC][artifact-synthesis] Typed symbolic artifact generation, validation, and repair substrate #407

New issue

Open

opened 2026-09-08 01:29:20 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-08 01:29:20 +00:00

Owner

Mission

Provide the reusable symbolic artifact-synthesis substrate needed by the authorized ZeroForge → Hackmode public port.

First downstream consumer: lost-rob0t/hackmode#191.

Publication/migration authority is tracked by:

#390 — private/reference semantics → public symbolic corpus;
lost-rob0t/hackmode#190 — public ZeroForge symbolic port;
private source record lost-rob0t/zero-forge#147.

This epic remains domain-neutral at the core. Cyber-specific module definitions, operation scope, execution providers and effect authority stay in Hackmode.

Problem

The expert system needs more than free-form text generation. Experts should be able to reason toward a typed artifact, produce a candidate, validate it, convert validation failures into facts, repair known failure classes, and only then return a verified artifact.

Target loop:

facts + objective + expert knowledge
        ↓
artifact applicability / family selection
        ↓
typed Artifact IR
        ↓
renderer/generator adapter
        ↓
validator adapter(s)
        ↓
validation evidence
        ↓
VERIFY artifact contract
        ↓
pass -> structured artifact result
fail -> diagnose -> repair rule/expert -> bounded retry

Relationship to first-class experts

Reuse #376 for expert registry/routing/invocation.

Expected generic expert families include:

artifact-family selector;
artifact requirements/planner expert;
validator expert;
validation-failure diagnosis expert;
repair expert;
artifact review/critic expert;
final artifact verification expert.

Do not create a second expert runtime for artifacts.

Typed Artifact IR

Define a generic representation sufficient to describe generated outputs without depending on Metasploit, ZAP or Hackmode-specific semantics.

Minimum concepts:

artifact_id
artifact_family
schema_version
objective_ref
source_fact_refs
requirements
constraints
assumptions
inputs
outputs
files/units
renderer_id/version
validator_set
success_oracle
provenance
candidate_state
validation_evidence
repair_history
verification_state

Downstream domains may extend the IR with closed typed fields.

Symbolic contracts

Support symbolic representation of artifact logic such as:

artifact_family(Family).
artifact_applicable(Family, Context).
requires_fact(Family, FactPattern).
requires_capability(Family, Capability).
incompatible_when(Family, Condition).
validator_for(Family, Validator).
validation_failure_class(Result, Class).
repair_for(Class, RepairExpert).
artifact_verified(Artifact, Evidence).

Exact predicate names should align with #376/#387 conventions rather than create parallel vocabulary unnecessarily.

Candidate generation

Artifact production may come from:

deterministic renderer;
symbolic/template composition;
expert-generated structured deltas;
explicit bounded LLM/RLM fallback.

A model-generated artifact is always a candidate until schema, policy and family validators succeed.

No model output gains execution/effect authority merely because validation passes.

Validation as evidence

Validators return typed evidence, not only booleans.

Generic result shape should capture:

validator identity/version;
input artifact digest/version;
pass/fail/warn/blocked;
machine-readable failure classes;
bounded diagnostic details;
generated evidence/artifacts;
runtime/environment identity when relevant;
elapsed/resource usage;
provenance.

These results become facts available to repair and verification experts.

Repair semantics

Known failures should prefer deterministic symbolic repair knowledge.

Example conceptual rules:

missing_required_field -> add/derive field if evidence exists
syntax_invalid -> route syntax repair expert
contract_violation -> repair constrained field set
validator_unavailable -> apply explicit policy (warn/block/alternate validator)
repeated_same_failure -> no-progress / escalate or stop

Generative repair is explicit fallback after deterministic repair cannot resolve the failure or the artifact necessarily requires generative synthesis.

Generic renderer / validator adapter contracts

Core exposes closed, typed adapter surfaces for:

render candidate from IR;
validate candidate;
normalize diagnostics;
report generated output refs/digests;
cancel/timeout;
deterministic replay metadata.

Adapters do not gain ambient host authority. Host-specific actions remain capability requests through #389.

ZeroForge / Hackmode first proving families

The first downstream conformance matrix should prove that this generic substrate can support Hackmode's public ZeroForge-derived families:

Metasploit module;
ZAP active script/plugin;
ZAP passive script/plugin;
native Hackmode exploit module;
native Hackmode detection module.

The cyber schemas/renderers/validators themselves remain downstream where appropriate.

Public symbolic-port integration

This epic consumes accepted public semantic artifacts from #390.

A private/reference behavior may therefore flow:

private authorized behavior
 -> #390 public symbolic rule/contract
 -> #376 artifact expert
 -> this epic's typed Artifact IR + validation loop
 -> Hackmode renderer/capability adapter
 -> public verified artifact

No private repository is required at runtime after migration.

Acceptance

typed generic Artifact IR exists with versioned schema;
artifact-family applicability can be decided by first-class experts/rules;
renderer and validator adapters use closed typed contracts;
validation returns structured evidence/failure classes;
validation evidence can be asserted into the reasoning state;
deterministic repair rules can route/modify typed candidates;
repeated same-failure/no-progress is detected;
model generation/repair is explicit, bounded, traced and candidate-only;
final artifact verification uses the unchanged artifact requirements/spec;
cancellation/budgets/replay integrate with canonical runtime;
public semantic-port artifacts from #390 can feed artifact experts;
deterministic synthetic tests cover pass, fail, repair-success, repair-exhausted and validator-unavailable paths;
Hackmode can implement all five initial ZeroForge-derived artifact families without a cyber-specific fork of this core runtime.

Non-goals

No Metasploit/ZAP-specific implementation in core.
No Hackmode target/operation authority in core.
No unrestricted generated executable invocation.
No automatic publication of private-source content.
No second scheduler/expert registry.

First slice

TDD a synthetic artifact family with one renderer and one validator. Prove: expert applicability -> Artifact IR -> render -> validator failure -> typed failure fact -> deterministic repair -> re-render -> pass -> final verification, with zero model calls.

## Mission Provide the reusable **symbolic artifact-synthesis substrate** needed by the authorized ZeroForge → Hackmode public port. First downstream consumer: `lost-rob0t/hackmode#191`. Publication/migration authority is tracked by: - #390 — private/reference semantics → public symbolic corpus; - `lost-rob0t/hackmode#190` — public ZeroForge symbolic port; - private source record `lost-rob0t/zero-forge#147`. This epic remains domain-neutral at the core. Cyber-specific module definitions, operation scope, execution providers and effect authority stay in Hackmode. ## Problem The expert system needs more than free-form text generation. Experts should be able to reason toward a typed artifact, produce a candidate, validate it, convert validation failures into facts, repair known failure classes, and only then return a verified artifact. Target loop: ```text facts + objective + expert knowledge ↓ artifact applicability / family selection ↓ typed Artifact IR ↓ renderer/generator adapter ↓ validator adapter(s) ↓ validation evidence ↓ VERIFY artifact contract ↓ pass -> structured artifact result fail -> diagnose -> repair rule/expert -> bounded retry ``` ## Relationship to first-class experts Reuse #376 for expert registry/routing/invocation. Expected generic expert families include: - artifact-family selector; - artifact requirements/planner expert; - validator expert; - validation-failure diagnosis expert; - repair expert; - artifact review/critic expert; - final artifact verification expert. Do not create a second expert runtime for artifacts. ## Typed Artifact IR Define a generic representation sufficient to describe generated outputs without depending on Metasploit, ZAP or Hackmode-specific semantics. Minimum concepts: ```text artifact_id artifact_family schema_version objective_ref source_fact_refs requirements constraints assumptions inputs outputs files/units renderer_id/version validator_set success_oracle provenance candidate_state validation_evidence repair_history verification_state ``` Downstream domains may extend the IR with closed typed fields. ## Symbolic contracts Support symbolic representation of artifact logic such as: ```prolog artifact_family(Family). artifact_applicable(Family, Context). requires_fact(Family, FactPattern). requires_capability(Family, Capability). incompatible_when(Family, Condition). validator_for(Family, Validator). validation_failure_class(Result, Class). repair_for(Class, RepairExpert). artifact_verified(Artifact, Evidence). ``` Exact predicate names should align with #376/#387 conventions rather than create parallel vocabulary unnecessarily. ## Candidate generation Artifact production may come from: 1. deterministic renderer; 2. symbolic/template composition; 3. expert-generated structured deltas; 4. explicit bounded LLM/RLM fallback. A model-generated artifact is always a **candidate** until schema, policy and family validators succeed. No model output gains execution/effect authority merely because validation passes. ## Validation as evidence Validators return typed evidence, not only booleans. Generic result shape should capture: - validator identity/version; - input artifact digest/version; - pass/fail/warn/blocked; - machine-readable failure classes; - bounded diagnostic details; - generated evidence/artifacts; - runtime/environment identity when relevant; - elapsed/resource usage; - provenance. These results become facts available to repair and verification experts. ## Repair semantics Known failures should prefer deterministic symbolic repair knowledge. Example conceptual rules: ```text missing_required_field -> add/derive field if evidence exists syntax_invalid -> route syntax repair expert contract_violation -> repair constrained field set validator_unavailable -> apply explicit policy (warn/block/alternate validator) repeated_same_failure -> no-progress / escalate or stop ``` Generative repair is explicit fallback after deterministic repair cannot resolve the failure or the artifact necessarily requires generative synthesis. ## Generic renderer / validator adapter contracts Core exposes closed, typed adapter surfaces for: - render candidate from IR; - validate candidate; - normalize diagnostics; - report generated output refs/digests; - cancel/timeout; - deterministic replay metadata. Adapters do not gain ambient host authority. Host-specific actions remain capability requests through #389. ## ZeroForge / Hackmode first proving families The first downstream conformance matrix should prove that this generic substrate can support Hackmode's public ZeroForge-derived families: - Metasploit module; - ZAP active script/plugin; - ZAP passive script/plugin; - native Hackmode exploit module; - native Hackmode detection module. The cyber schemas/renderers/validators themselves remain downstream where appropriate. ## Public symbolic-port integration This epic consumes accepted public semantic artifacts from #390. A private/reference behavior may therefore flow: ```text private authorized behavior -> #390 public symbolic rule/contract -> #376 artifact expert -> this epic's typed Artifact IR + validation loop -> Hackmode renderer/capability adapter -> public verified artifact ``` No private repository is required at runtime after migration. ## Acceptance - [ ] typed generic Artifact IR exists with versioned schema; - [ ] artifact-family applicability can be decided by first-class experts/rules; - [ ] renderer and validator adapters use closed typed contracts; - [ ] validation returns structured evidence/failure classes; - [ ] validation evidence can be asserted into the reasoning state; - [ ] deterministic repair rules can route/modify typed candidates; - [ ] repeated same-failure/no-progress is detected; - [ ] model generation/repair is explicit, bounded, traced and candidate-only; - [ ] final artifact verification uses the unchanged artifact requirements/spec; - [ ] cancellation/budgets/replay integrate with canonical runtime; - [ ] public semantic-port artifacts from #390 can feed artifact experts; - [ ] deterministic synthetic tests cover pass, fail, repair-success, repair-exhausted and validator-unavailable paths; - [ ] Hackmode can implement all five initial ZeroForge-derived artifact families without a cyber-specific fork of this core runtime. ## Non-goals - No Metasploit/ZAP-specific implementation in core. - No Hackmode target/operation authority in core. - No unrestricted generated executable invocation. - No automatic publication of private-source content. - No second scheduler/expert registry. ## First slice TDD a synthetic artifact family with one renderer and one validator. Prove: expert applicability -> Artifact IR -> render -> validator failure -> typed failure fact -> deterministic repair -> re-render -> pass -> final verification, with zero model calls.