Compression Doctrine

Compression Doctrine is a prompt

At the implementation level, Compression Doctrine is a prompt-based policy. The core rules live in compression-rules.ts and are injected into the model through the compression system prompt. They do not compute a relevance score or run a separate classifier; they instruct the model how to make the judgment itself.

1. When should information be compressed?

Ask whether the information has finished its job for the current task step.

If the model still needs to directly use it, keep it raw. If not, it becomes a compression candidate.

This is why age alone is not the criterion:

• old but still needed → keep
• recent but already consumed → compress

2. What must survive?

Preserve the information that future work may still depend on:

• goals and user intent
• constraints
• decisions and rationale
• exact load-bearing technical details
• open objectives, questions, and TODOs
• message refs when source recovery may be needed

3. What can disappear?

Drop the vessel after extracting the signal. Typical examples include:

• verbose logs once the error or result is captured
• duplicate reads
• consumed exploration
• intermediate discussion and self-correction
• repeated status checks

Dead ends can disappear too, but their lesson should survive in compact form: tried X, failed because Y.

4. When space is tight

Preserve in this order:

1. Goal / intent / constraints
2. Decisions + rationale
3. Exact technical artifacts
4. Conclusions / findings
5. Lessons learned

In short:

When? Has it finished its job?

Keep? Preserve what future work depends on.

Drop? Remove consumed process after extracting the signal.

Prioritize? goal → decisions → artifacts → conclusions → lessons.

Read the source: acp-kernel/src/compression-rules.ts ↗