Documentation for metadata usage in end-to-end security DAG

[superdosh]

• A single, rich example of metadata being passed along a full jailbreak DAG (e.g. here https://github.com/mlcommons/modelplane-flights/blob/main/evaluators/security/end_to_end.ipynb)
• In particular, knowing that we might have hazard, jailbreak type, bijection mapping all in the input CSV. Assume at least one node creates metadata that a downstream node uses.

#153
https://github.com/mlcommons/modelplane-flights/pull/29

[mindbomber]

This metadata example is exactly where an AANA-style verifier-gated record can help without changing the benchmark's scoring model.

For a full jailbreak/security DAG, I would suggest making at least one example show metadata being created by an upstream node and consumed by a downstream gate/evaluator. For example:

{
  "sample_id": "...",
  "hazard": "cyber | self-harm | fraud | ...",
  "jailbreak_type": "...",
  "bijection_mapping_ref": "...",
  "evidence_refs": [
    {
      "source_id": "input_csv:row_id",
      "kind": "benchmark_metadata",
      "trust_tier": "benchmark_provided",
      "redaction_status": "safe_for_public_log"
    }
  ],
  "gate_result": {
    "route": "accept | revise | ask | defer | refuse",
    "hard_blockers": [],
    "missing_evidence": [],
    "audit_status": "safe_for_public_log"
  }
}

This gives downstream nodes a standard way to say: "I used the hazard/jailbreak metadata and this evidence object to make the route decision." It also makes false accepts, false refusals, and deferrals inspectable after the run.

I can help turn this into a compact docs/example PR against the end-to-end security DAG documentation if that would be useful. I would keep it dependency-free and generic, with AANA only as the motivating pattern.