[NSoC] Implement metadata extraction for Advanced Analytical Wards

[Sid-352]

Arbiter needs deeper file inspection capabilities for its analytical wards. We need to extract specific metadata from files during processing.

Tasks:

• Implement extraction logic for EXIF metadata from images.
• Implement MIME type detection for complex binaries.
• Implement page counting for PDF files.
• Integrate these extraction methods into the existing file inspection flow.
• Create new unit tests as required for each new ward data.

Constraints:

• CRITICAL: DO NOT modify the formatting macros or the structural layout of the ActionType enum. Arbiter engine relies on a strict Bincode serialization strategy between the UI and the storage ledger. Altering ActionType will result in a SerializationFailed error and cause data loss. Map your new extraction types carefully without breaking this boundary.

[Moresh-Mishra]

@Sid-352 i would like to work on this as NSOC'26 contributor

[Sid-352]

@Moresh-Mishra Assigned.

Since this is a Level 2 enhancement, it touches actual engine logic. Before you write a single line of code, drop a brief outline of your approach in this thread (e.g., what structs you plan to modify, how it hooks into the existing state).

If you just dump a massive PR without explaining how it fits the architecture, it will be rejected.

Read CONTRIBUTING.md. Follow the guidelines given. Keep the CI green.

[Moresh-Mishra]

So this is what i came through:
The core idea is to keep ActionType completely untouched — arbiter-core/src/decree.rs stays as-is to avoid breaking any serialization boundaries. Instead, we'll layer new analytical keys on top of the existing EnvKey + EnvContext pipeline in that same file, right alongside where content_mime, content_sha256, content_entropy, and text_lines are already being computed.
On the watcher side, we don't need to add anything new. The file watcher in arbiter-core/src/vigil.rs already handles source_path and integrity_scan based on the ward layer, so we'll just lean on that to gate the new metadata.

arbiter-core/src/decree.rs
Most of the work lands here. We'll add new analytical env keys — pdf_pages for sure, and EXIF fields that either map to the existing img_model/img_gps keys or get new ones if needed. Each new key gets its own cache (same pattern as mime_cache and text_lines_cache) so lazy resolution stays isolated and doesn't slow anything down. The actual computation lives in new compute_* helpers — one for EXIF extraction, one for deep MIME detection fallback, one for PDF page counting — all gated behind vigil-deep. The resolve() function will call these only when the key is actually requested and integrity_scan is true, so there's no unnecessary work on the hot path.
arbiter-core/Cargo.toml
Any new crates get added under the vigil-deep feature flag, keeping deep inspection strictly opt-in. Builds that don't need analytical features stay lean. The feature flag is already defined here, so it's just a matter of extending it.

Testing plan
Unit tests go in arbiter-core alongside the compute helpers, covering three scenarios: EXIF extraction (against an image that actually has model/GPS fields), MIME detection for a binary that infer tends to misclassify without a deeper read, and PDF page counting against a fixture with a known page count. All tests are gated on vigil-deep and use small fixtures to keep CI snappy.

A few things to nail down before we start

EXIF scope — are img_model and img_gps enough, or do we also want img_make, img_datetime, and img_orientation exposed?
MIME detection — deeper read + infer only, or bring in a dedicated crate (magic-bytes with extension fallback)?
PDF page counting — fine to pull in a pure-Rust PDF parser, or would you rather keep it minimal and just scan for /Type /Page?

Please know that i have a very little knowledge of rust but still took this up beacuse wanted to start somewhere with rust
While these changes we made with the AI, i have thouroughly understood the project before asking for the issue
I also have understood the issue and had a back-and-forth conversation with the AI to come to this overview.

If you approve this i would continue ahead

[Sid-352]

@Moresh-Mishra Appreciate the transparency regarding your Rust experience and your use of AI to map out the architecture. Because you took the time to respect the existing serialization boundaries and feature gates, you have the green light to proceed. But on a few conditions.

To answer the questions:

• EXIF Scope: Keep it strictly to img_model and img_gps for now. One can expand the enum later if needed, do not bloat the initial implementation.
• MIME Detection: Stick to infer with a lightweight extension fallback IF needed. Do not pull in something like libmagic bindings.
• PDF Page Counting: Absolutely keep it minimal. Do not pull in a full PDF parsing crate. Massive overkill. A fast, raw byte scan for /Type /Page boundaries should be enough.

Take it one feature at a time. Start with the EXIF extraction, get the tests to pass, and open a draft PR so I can review the implementation before you move on to anything else. You must and I mean must test every change and addition manually and via the automated tests. Arbiter will fail in weird ways, and you'll have to look at logs and tests to see the Point of Failure.

[Moresh-Mishra]

Appreciate your response and will get right into it

[ankitasahu83964]

Hi, I would like to work on this issue under NSoC'26.
Could you please assign it to me?

[Sid-352]

@ankitasahu83964 Thanks for your interest, but this issue is already assigned to @Moresh-Mishra and he is actively working on the implementation.

Please look for other unassigned issues on the tracker later. If this one opens back up, I will update the thread.

[ankitasahu83964]

@ankitasahu83964 Thanks for your interest, but this issue is already assigned to @Moresh-Mishra and he is actively working on the implementation.

Please look for other unassigned issues on the tracker later. If this one opens back up, I will update the thread.

ok