Add correlation_id across receipts, verifier context, and logs

[OkeyAmy]

Problem

Operators need a simple way to connect related invocations during debugging and audit review. Today that requires too much chain-walking. correlation_id is useful now; budget and live call limits are a separate product decision.

What to do

Add optional correlation_id support across the product surface:

• receipt types where appropriate
• SDK issuance helpers
• verifier result context
• structured logs
• docs explaining intended use

Acceptance criteria

• SDK can issue receipts with correlation_id
• verifier preserves and returns it when present
• structured logs include it
• absence remains valid
• tests cover issuance, verification, and logging behavior

Out of scope

• budget enforcement
• max_calls runtime counters
• billing or spend-control semantics

[Keesan12]

This is the right issue.

I would make one distinction explicit in the design: correlation and budget carriage are tracing / enforcement inputs, but the receipt also needs a terminal reason field once a budget or call ceiling actually stops the run.

Otherwise operators can tell a chain was linked, but not why it ended where it did.

The useful envelope in practice is usually something like:

• correlation_id
• budget / ceiling config
• observed usage so far
• halt_reason
• parent / root linkage

That makes the audit trail answer the two real questions: what was authorized, and why was the next call no longer admitted. That runtime seam has been pretty central in the work I have been doing around MartinLoop.

[OkeyAmy]

Yeah, you are right. Having operators know exactly why a call or next step was not admitted makes the traceability much stronger across the whole run chain.

I also like the distinction between tracing inputs and terminal enforcement state with "halt_reason".

Happy to discuss more about what you are building around MartinLoop as well