osint: bake the dual-use facet edges into osint_scene.soa (fix free-floating dimensions)#45
Conversation
The served OSINT asset predated PR #44's entity->SchemaValue facet edges (rel 10-15), so the dual-use dimension cluster (127 SchemaValue + 12 SchemaAxis) rendered as a 139-node island: connected only to itself via VALID_FOR, touching the entity graph at zero points. In the cockpit it floated free regardless of the dimensions toggle. cockpit-server's own re-bake OOMs at the disk cap (lance+datafusion+arrow+ deno/V8), so lift the pure bake (aiwar-ingest + zero-dep lance-graph- contract, no heavy closure) into a light tool crate, osint-bake, and regenerate the asset through the REAL Rust path -- not a Python splice, which would have diverged (the real bake emits 431 facet edges; an earlier label-join estimate said 438). Verified by decoding the bytes (before -> after): - nodes 920 unchanged, GUID section byte-identical - edges 3344 -> 3775 (+431 facet edges, rel 10-15; 0 originals changed) - dimension<->entity bridges: {} -> System 297, Stakeholder 122, Hist 12 - BFS from a System now reaches 118/127 SchemaValues, 10/12 SchemaAxes => the dimensions share the entity graph's connected component The 12 SchemaAxis nodes are the family/category nodes; the facet edges make them connective tissue (entity -> value -> VALID_FOR -> axis) rather than a detached legend. osint-bake's bake is verbatim-identical to osint_gotham.rs's (single source of truth until cockpit-server delegates to it -- deferred; that edit needs a cockpit-server build to verify, blocked by the disk cap). Builds clean, 7/7 tests pass, clippy-clean. cockpit-server itself is untouched. Incidental: osint_gotham.rs's soa_bytes_have_a_parseable_header test hard-equates byte length to the fixed records and is stale (predates the OSO1 label tail); corrected in the mirror, original still needs the fix. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TzqvDqbFRzyx17EkLKBoZF
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
More reviews will be available in 6 minutes and 49 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses rolling per-developer review limits. Reviews become available again as older review attempts age out of the rolling limit window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Slice 1 of the dual-use "both layers" plan: keep the materialized facet edges (PR #45 — the reference layer) AND add the dynamic per-node tenant (the residual layer the cockpit groups by live). Bake (osint-bake): - Emit value[1..=6] (militaryUse, civicUse, airo:type, MLType, purpose, capacity) as an additive OSO1 tenant tail: 6 bytes/node after the label tail. Old readers stop after labels; new readers consume it. - Fix a non-deterministic bake. >15 enrichment themes clamp to ti=15, so their (15<<4)|nib basins collide in anchor_of_basin and a HashMap iteration let the surviving hub label depend on the hash seed (the asset SHA varied run-to-run in the basin-hub label tail only; node GUIDs/family/ edges/tenants were already stable). Iterate themes sorted -> reproducible asset. osint-bake now leads osint_gotham.rs (legacy copy) on the tenant tail and this fix; both land there at the delegation de-dup. Cockpit (OsintGraph.tsx): - Decode the tenant tail. - Facet lens: 6 axis chips recolour every node by its tenant code on the chosen axis (a live group-by across all nodes), with a value->count legend named from the facet edges. Coexists with the dimensions toggle, so both layers show at once. Verified: osint-bake 8/8 tests + clippy clean; asset deterministic across 3 regens (920 nodes, 3775 edges, 431 facet edges, 183 nodes carry a tenant); cockpit `tsc && vite build` clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TzqvDqbFRzyx17EkLKBoZF
2 participants
Problem
mainalready has PR #44's facet-edge code — the bake emits entity toSchemaValueedges (rel 10-15) and the cockpit client renders them — but the servedosint_scene.soawas baked before #44, so it carries 0 facet edges. The dual-use dimension cluster (127SchemaValue+ 12SchemaAxis) is therefore a 139-node island: connected only to itself viaVALID_FOR, touching the entity graph at zero points. The cockpit's force layout has nothing to pull it in, so the dimensions float free regardless of the dimensions toggle.Why a new crate instead of just re-running the bake
The bake lives in
cockpit-server(osint_gotham.rs::osint_soa_bytes), invoked only by the#[ignore]dbake_osint_soatest. Re-running it requires compiling cockpit-server's full closure (lance + datafusion + arrow + deno/V8), which OOMs at the disk cap here. But the bake's true closure is light:aiwar-ingest+ zero-deplance-graph-contract.So this lifts the pure bake into a small tool crate,
crates/osint-bake/, and regenerates the asset through the real Rust path — not a Python splice, which would have diverged (the real bake emits 431 facet edges; an earlier label-join estimate said 438, because it couldn't reproduce the id-keyed join over the enriched node set).osint-bake's logic is verbatim-identical toosint_gotham.rs's pure bake (single source of truth until cockpit-server is wired to delegate to it — see "Follow-ups").Result (verified by decoding the bytes, before to after)
{}(island)The 12
SchemaAxisnodes are the family/category nodes; the facet edges make them connective tissue (entity to value toVALID_FORto axis) instead of a detached legend. Sample:Large Geospatial Models -militaryUse-> Intelligence,-civicUse-> AR/Games,-purpose-> PredictiveMapping,-capacity-> ImageGeneration.osint-bake: builds clean, 7/7 tests pass (incl. the keystone facet test), clippy-clean. cockpit-server is untouched.Verification
Follow-ups (not in this PR)
osint_gotham.rsatosint-bakeand delete its duplicate bake. Deferred because verifying that edit needs a cockpit-server build (disk-blocked here).osint_gotham.rs::soa_bytes_have_a_parseable_headerhard-equates byte length to the fixed node+edge records — it predates the OSO1 label tail and is stale (would fail if run). Corrected in the mirror; the original needs the same one-line>=fix.🤖 Generated with Claude Code
https://claude.ai/code/session_01TzqvDqbFRzyx17EkLKBoZF