[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-nitro-split-kernel-isolation-math-en":3,"article-related-nitro-split-kernel-isolation-math-en":30,"series-research-8abdf0aa-3fa8-4123-adec-4b0d3cd6b7de":75},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"8abdf0aa-3fa8-4123-adec-4b0d3cd6b7de","nitro-split-kernel-isolation-math-en","Nitro’s split kernel turns isolation into math","\u003Cp data-speakable=\"summary\">\u003Ca href=\"\u002Ftag\u002Faws\">AWS\u003C\u002Fa> split Nitro’s isolation logic into a tiny \u003Ca href=\"\u002Ftag\u002Frust\">Rust\u003C\u002Fa> kernel and proved VM isolation with machine-checked math.\u003C\u002Fp>\u003Cp>I’ve been around enough cloud security systems to know when something feels too big to trust. You get a hypervisor with drivers, policy code, AWS-specific hooks, scheduling, and a pile of special cases, and then someone says, “don’t worry, it isolates VMs.” Sure. I’ve seen that movie. The problem isn’t that the team is sloppy. The problem is that once the isolation logic is buried inside everything else, you can’t reason about it cleanly anymore. Every change becomes a “probably fine” change, which is not a sentence I like hearing from security software.\u003C\u002Fp>\u003Cp>What caught my attention in Amazon Science’s write-up was not the usual cloud bragging. It was the decision to split the isolation logic out into a separate piece, keep it tiny, and then prove properties about it with machine-checked mathematics. That’s the kind of move I wish more platform teams made before they shipped the mess. It’s also the kind of move that makes the whole system easier to audit, easier to explain, and, frankly, less dependent on vibes.\u003C\u002Fp>\u003Cp>The source that triggered this breakdown is Amazon Science’s post, \u003Ca href=\"https:\u002F\u002Fwww.amazon.science\u002Fblog\u002Fec2s-formally-verified-isolation-engine-provides-mathematical-assurance-of-virtual-machine-isolation\">“EC2’s formally verified ‘isolation engine’ provides mathematical assurance of virtual-machine isolation”\u003C\u002Fa>, by Dominic Mulligan and Nathan Chong. Amazon says the model and proof are 330,000 lines of machine-checked mathematics, and that the Nitro Isolation Engine is the first formally verified hypervisor deployed in a commercial cloud environment. That’s the hook. The interesting part is how they got there.\u003C\u002Fp>\u003Ch2>Stop trying to verify the whole hypervisor\u003C\u002Fh2>\u003Cblockquote>“Splitting the ‘separation kernel’ off from the rest of the Nitro security system … enabled its formal verification.”\u003C\u002Fblockquote>\u003Cp>What this actually means is simple: they stopped pretending the whole hypervisor was a good candidate for proof. That’s a hard-earned lesson. If your system mixes isolation policy, device handling, scheduling, migration, and product-specific glue, you’re not verifying a kernel anymore. You’re signing up to prove a sprawling application that happens to sit under VMs.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781843602176-04ij.png\" alt=\"Nitro’s split kernel turns isolation into math\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>Amazon’s post says the old Nitro Hypervisor handled isolation plus business logic, device drivers, and AWS-specific features. That’s exactly the kind of architecture that makes formal verification balloon into a nightmare. The team pulled out the one thing that really matters for VM separation and made it its own component: the Nitro Isolation Engine. That smaller target is what they could actually reason about.\u003C\u002Fp>\u003Cp>I’ve run into this pattern in real systems work. If you ask engineers to “prove security” for a giant service, they start by narrowing the scope anyway. They’ll pick one invariant, one data flow, one boundary. Amazon just made that move explicit instead of hiding it in a slide deck. That’s the difference between a proof plan and wishful thinking.\u003C\u002Fp>\u003Cp>How to apply it: identify the one subsystem where a mistake becomes a security incident, then strip everything else away from it. If you can’t reduce the surface area, you probably can’t verify it. And if your architecture forces verification to include unrelated features, the architecture is the problem.\u003C\u002Fp>\u003Cul>\u003Cli>Separate enforcement from policy.\u003C\u002Fli>\u003Cli>Keep the proof target minimal.\u003C\u002Fli>\u003Cli>Let the rest of the system ask for help instead of owning the security boundary.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>This is also why the “separation kernel” idea matters. John Rushby coined the term in 1981 to describe a minimal OS component that partitions a system into isolated compartments. Amazon is basically applying that old idea in a cloud setting, where the stakes are higher and the codebase is messier.\u003C\u002Fp>\u003Ch2>Rust helped, but only because they used less of it\u003C\u002Fh2>\u003Cp>Amazon says the Nitro Isolation Engine was written in Rust, but not the whole language. They used only a subset that plays nicely with formal reasoning. That matters. A lot of teams say they want Rust because it’s “safer,” then proceed to use every feature available and wonder why the proof story still hurts.\u003C\u002Fp>\u003Cp>The point here is not “Rust makes everything verified.” The point is “restrict the language until the semantics are tractable.” That’s a very different statement. They also built a formalization of a core subset of Rust, called μRust, as part of the open-sourced \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fawslabs\u002Fautocorrode\">AutoCorrode\u003C\u002Fa> library. That gives them a proof-friendly model of the code they actually wrote.\u003C\u002Fp>\u003Cp>I like this because it acknowledges a truth people hate admitting: verification is as much about language design as it is about logic. If your implementation language has too many sharp edges, the proof ends up chasing the language instead of the system. I’ve seen teams get buried in aliasing rules, undefined behavior, and weird compiler assumptions. At that point, the proof assistant is not the hard part. The programming model is.\u003C\u002Fp>\u003Cp>How to apply it: if you want to verify a subsystem, define a “safe subset” first. Don’t start from the language manual. Start from the operations the subsystem actually needs. Then ban the rest. That means fewer features, fewer abstractions, and fewer clever tricks. Annoying? Yes. Effective? Also yes.\u003C\u002Fp>\u003Cul>\u003Cli>Write down the subset before you write code.\u003C\u002Fli>\u003Cli>Prefer boring data structures.\u003C\u002Fli>\u003Cli>Make unsafe escape hatches rare and obvious.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Amazon’s choice to formalize a Rust subset is the part I’d copy first. Not because Rust is magic, but because restraint is what makes the rest of the proof possible. The code becomes smaller in meaning, not just smaller in lines.\u003C\u002Fp>\u003Ch2>Proofs only work when the specs are painfully explicit\u003C\u002Fh2>\u003Cp>Amazon breaks the verification into two halves: specifications and proofs. That sounds obvious until you’ve tried to write a spec that doesn’t smuggle in assumptions from your implementation. Then you discover how much hand-waving your team has been living on.\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781843600778-rgfo.png\" alt=\"Nitro’s split kernel turns isolation into math\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>Their theorems cover four property classes: confidentiality and integrity, functional correctness, absence of runtime errors, and memory safety. I appreciate that they separate confidentiality and integrity from the rest. Those are not just “nice security properties.” They’re the actual reason a cloud customer cares about VM isolation in the first place.\u003C\u002Fp>\u003Cp>What this actually means is that the engine isn’t just “safe code.” It is a machine-checked argument that guest memory gets scrubbed before reuse, that only authorized information flows happen, and that the implementation behaves as specified. That’s a much more concrete claim than “we audited it.”\u003C\u002Fp>\u003Cp>I’ve been in code reviews where “secure” really meant “we looked at it and didn’t see anything obvious.” That is not the same category of statement. A formal spec forces you to define terms like “authorized,” “reuse,” and “guest state” in a way the proof assistant can check. That hurts at first, because it exposes the fuzzy parts. Then it helps, because the fuzzy parts were where bugs were hiding.\u003C\u002Fp>\u003Cp>How to apply it: before you talk about proof tools, write the properties in plain English with no marketing language. Then make each one measurable. If you can’t say what violates the property, you don’t have a spec yet.\u003C\u002Fp>\u003Cp>Useful links if you want to see the machinery around this work: \u003Ca href=\"https:\u002F\u002Fisabelle.in.tum.de\u002F\">Isabelle\u002FHOL\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fwww.nitro-enclaves.org\u002F\">AWS Nitro\u003C\u002Fa>, and the \u003Ca href=\"https:\u002F\u002Fwww.amazon.science\u002Fblog\u002Fec2s-formally-verified-isolation-engine-provides-mathematical-assurance-of-virtual-machine-isolation\">Amazon Science article\u003C\u002Fa> itself. The proof stack matters because the properties are only as good as the formal language you choose to express them.\u003C\u002Fp>\u003Ch2>They proved the boundary, not the whole cloud\u003C\u002Fh2>\u003Cp>One thing I think Amazon gets right here is scope discipline. The Nitro Isolation Engine is not the entire cloud. It is the enforcement point for VM isolation. The Nitro Hypervisor still handles policy like VM creation, resource allocation, migration, and scheduling, but it has been deprivileged. It has to ask the engine before touching guest state.\u003C\u002Fp>\u003Cp>That is a clean security shape. The policy layer can be messy, feature-rich, and product-driven. The enforcement layer stays small, auditable, and proof-friendly. That split also gives customers something concrete to trust: the component that actually guards VM boundaries is the one that got the math treatment.\u003C\u002Fp>\u003Cp>I’ve seen teams blur this line all the time. They’ll say “the platform is secure,” but the enforcement logic is spread across half a dozen services. Then an incident happens and nobody can tell which layer owned the decision. Amazon’s architecture avoids that nonsense by making the boundary explicit.\u003C\u002Fp>\u003Cp>How to apply it: if you have a security-critical boundary, make one component the only place that can enforce it. Everything else should request actions, not perform them directly. That makes it easier to test, easier to audit, and much easier to prove.\u003C\u002Fp>\u003Cul>\u003Cli>Keep policy in the outer layers.\u003C\u002Fli>\u003Cli>Keep enforcement in one narrow core.\u003C\u002Fli>\u003Cli>Make every state-changing action pass through that core.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>This is also why the “always-on” detail matters. Amazon says the Nitro Isolation Engine is an always-on feature for Graviton5 users. That means this isn’t a lab demo or a niche mode. It’s the actual production path. I care about that because proof work is easy to admire when it lives in a paper and hard to respect when it has to survive real traffic.\u003C\u002Fp>\u003Ch2>330,000 lines is not the flex people think it is\u003C\u002Fh2>\u003Cp>Amazon says the Isabelle\u002FHOL model and proof comprise 330,000 lines of machine-checked mathematics, comparable in scale to seL4. That number is impressive, but I don’t read it as “look how huge the proof is.” I read it as “this is what it costs to make a serious claim about a serious system.”\u003C\u002Fp>\u003Cp>The comparison to \u003Ca href=\"https:\u002F\u002Fsel4.systems\u002F\">seL4\u003C\u002Fa> matters because seL4 is the project people point to when they want proof-based operating systems to sound real instead of academic. Amazon is saying, in effect, we are in that same territory now, except the target is a commercial cloud hypervisor shipping on production hardware.\u003C\u002Fp>\u003Cp>What this actually means is that formal verification doesn’t stay tiny once the system gets real. The trick is not keeping the proof microscopic. The trick is keeping the part you need to prove microscopic enough that the proof is still possible. That’s a very different engineering bargain.\u003C\u002Fp>\u003Cp>I’ve watched people underestimate proof size because they imagine a theorem as a neat little paragraph. That’s not how industrial verification works. The proof becomes an engineering artifact. It needs structure, naming discipline, and maintenance plans. If that makes you uncomfortable, good. It should. Security claims deserve more than a one-liner in a README.\u003C\u002Fp>\u003Cp>How to apply it: don’t ask “can we prove this in a weekend?” Ask “what part of the system deserves this level of rigor?” Then budget for the proof as real engineering work, not research theater.\u003C\u002Fp>\u003Cp>If you want to go deeper, Amazon’s post points to a white paper and a re:Invent talk from 2025. Those are the places where the scope and assumptions are spelled out more formally than a blog post can manage. That’s where I’d go next if I were evaluating whether the proof covers the guarantees I care about.\u003C\u002Fp>\u003Ch2>The real lesson is architectural humility\u003C\u002Fh2>\u003Cp>The most useful thing in this whole story is not that Amazon used Isabelle\u002FHOL, or that the code is in Rust, or even that they hit 330,000 lines of proof. It’s that they were willing to admit the original system was too broad to verify as-is. So they changed the architecture until the proof became possible.\u003C\u002Fp>\u003Cp>That’s the part I wish more engineering orgs would copy. Too often, teams treat formal verification like a bolt-on badge. They keep the architecture, keep the complexity, and then ask a theorem prover to bless the mess. That’s backwards. The architecture has to cooperate.\u003C\u002Fp>\u003Cp>Amazon’s split between policy and enforcement is the kind of move that pays off even if you never run the proof. It clarifies responsibilities, reduces hidden coupling, and gives security reviewers a smaller target. The formal verification just makes those benefits harder to ignore.\u003C\u002Fp>\u003Cp>How to apply it: when a system is too complex to reason about, don’t just add more tests. Ask what can be separated, deprivileged, or reduced to a smaller trusted core. If the answer is “nothing,” that’s usually the real problem.\u003C\u002Fp>\u003Cp>And yes, this is the kind of thing cloud customers should care about even if they never read a proof. Because the proof isn’t the product. The product is the architecture that made the proof possible.\u003C\u002Fp>\u003Ch2>The template you can copy\u003C\u002Fh2>\u003Cpre>\u003Ccode># Formal-verification-friendly security core template\n\n## 1) Define the boundary\n- Name the exact security property this component enforces.\n- Keep it to one sentence.\n- Example: \"This component enforces isolation between tenants\u002FVMs\u002Fprocesses.\"\n\n## 2) Split policy from enforcement\n- Policy decides what should happen.\n- Enforcement decides whether it is allowed and performs the state change.\n- The enforcement core must be the only place that can touch sensitive state.\n\n## 3) Minimize the trusted core\n- Move everything unrelated out of the proof target:\n  - scheduling\n  - device drivers\n  - feature flags\n  - product-specific glue\n- Leave only the code that must be correct for the security boundary.\n\n## 4) Restrict the implementation language\n- Define a safe subset of the language.\n- Ban features that complicate reasoning unless they are absolutely required.\n- Prefer simple data structures and explicit state transitions.\n\n## 5) Write machine-checkable specs\nFor each property, write:\n- what must always be true\n- what counts as a violation\n- what inputs\u002Fstates are in scope\n- what assumptions the proof is allowed to make\n\n## 6) Prove four classes of properties\n- Confidentiality: no unauthorized information flow\n- Integrity: no unauthorized state modification\n- Functional correctness: implementation matches the spec\n- Safety: no runtime errors, no memory unsafety\n\n## 7) Make the outer system request, not decide\n- The outer layer can create, schedule, allocate, or migrate.\n- It must ask the core before touching protected state.\n- The core returns allow\u002Fdeny and performs the sensitive action itself.\n\n## 8) Keep the proof honest\n- Document scope.\n- Document assumptions.\n- Document what is not proved.\n- Treat the proof as an engineering artifact that needs maintenance.\n\n## 9) Copy-ready architecture sketch\n\n[Policy layer]\n- VM creation\n- Resource allocation\n- Scheduling\n- Migration\n- Product-specific features\n\n        |\n        v\n\n[Verification boundary]\n- Authorization check\n- State transition\n- Guest-memory scrubbing\n- Isolation enforcement\n- Error handling\n\n        |\n        v\n\n[Protected state]\n- Guest memory\n- VM metadata\n- Isolation metadata\n- Device access state\n\n## 10) Copy-ready spec starter\n- The enforcement core never allows two tenants to observe each other’s protected state.\n- Any reused guest memory is scrubbed before reassignment.\n- Every state transition is authorized by the core.\n- The implementation never performs an out-of-bounds access.\n- The implementation never dereferences invalid memory.\n\n## 11) Copy-ready review checklist\n- Is the proof target small enough to explain in one paragraph?\n- Can the outer system fail without violating isolation?\n- Does every sensitive transition go through one core?\n- Are runtime and memory safety part of the claim?\n- Are the assumptions written down instead of implied?\n\n## 12) Copy-ready prompt for your team\n\"List the smallest subsystem that, if proven correct, would give us confidence in the security boundary. Remove everything else from the proof target. Then define the exact properties we need to prove, the language subset we will allow, and the assumptions we are willing to make.\"\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>What I’d copy from Amazon is not the scale, but the discipline: isolate the security boundary, keep the proof target small, and force the implementation to fit the proof instead of the other way around. That’s the part teams can actually use.\u003C\u002Fp>\u003Cp>Source attribution: this breakdown is based on Amazon Science’s article at \u003Ca href=\"https:\u002F\u002Fwww.amazon.science\u002Fblog\u002Fec2s-formally-verified-isolation-engine-provides-mathematical-assurance-of-virtual-machine-isolation\">amazon.science\u003C\u002Fa>. Everything here is my interpretation and reorganization of that source, plus a practical template I wrote for developers who want to apply the same pattern elsewhere.\u003C\u002Fp>","How AWS split Nitro’s isolation logic into a tiny Rust kernel and proved VM isolation with machine-checked math.","www.amazon.science","https:\u002F\u002Fwww.amazon.science\u002Fblog\u002Fec2s-formally-verified-isolation-engine-provides-mathematical-assurance-of-virtual-machine-isolation",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781843602176-04ij.png","research","en","01a0e759-2366-485d-bafa-db75293c9f0c",[17,18,19,20,21],"formal verification","AWS Nitro","Rust","hypervisor","separation kernel",[23,24,25],"Split the security boundary from the rest of the system before trying to prove anything.","Restrict the language and the proof target until the system becomes tractable.","Treat formal verification as an architectural decision, not a badge you add later.",0,"2026-06-19T04:32:58.564142+00:00","2026-06-19T04:32:58.553+00:00","3103988e-c4fe-45e3-98ab-846500c9d507",{"tags":31,"relatedLang":34,"relatedPosts":38},[32],{"name":19,"slug":33},"rust",{"id":15,"slug":35,"title":36,"language":37},"nitro-split-kernel-isolation-math-zh","Nitro 把隔離拆成可證明的數學","zh",[39,45,51,57,63,69],{"id":40,"slug":41,"title":42,"cover_image":43,"image_url":43,"created_at":44,"category":13},"405de39d-cfc5-43bf-b47b-ff9ce7be96a9","turboquant-does-not-hurt-search-quality-equal-bytes-en","TurboQuant does not hurt search quality at equal byte budgets","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781857967113-2xax.png","2026-06-19T08:32:22.235692+00:00",{"id":46,"slug":47,"title":48,"cover_image":49,"image_url":49,"created_at":50,"category":13},"66286461-18c3-42a2-a053-16a87b9a0dd0","deterministic-multicalibration-optimal-sample-use-en","Deterministic multicalibration finally hits optimal sample use","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781850768283-gcmj.png","2026-06-19T06:32:28.768728+00:00",{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"6dc0410b-c9ec-4148-974b-0b5f7a14975c","uniego-proxy-teachers-egocentric-video-en","UNIEGO unifies egocentric video with proxy teachers","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781849887430-g735.png","2026-06-19T06:17:32.327109+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"b398938d-f651-4d91-bfee-d888ba44fe6f","diffusiongemma-transparency-measured-en","DiffusionGemma’s transparency problem, measured","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781848969642-b497.png","2026-06-19T06:02:30.672396+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"39d1ecdc-5ce6-45b7-af63-f1b74337311d","blackwell-wins-agentic-ai-infrastructure-benchmark-en","Blackwell wins because agentic AI needs full-stack infrastructure","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781803966380-s5kc.png","2026-06-18T17:32:18.823071+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"d7f11606-750d-42ea-87b8-23a761269509","locus-local-ordinance-corpus-us-en","LOCUS opens U.S. local law for legal AI","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1781764376812-ikxd.png","2026-06-18T06:32:30.210741+00:00",[76,81,86,91,96,101,106,111,116,121],{"id":77,"slug":78,"title":79,"created_at":80},"a2715e72-1fe8-41b3-abb1-d0cf1f710189","ai-predictions-2026-big-changes-en","AI Predictions for 2026: Brace for Big Changes","2026-03-26T01:25:07.788356+00:00",{"id":82,"slug":83,"title":84,"created_at":85},"8404bd7b-4c2f-4109-9ec4-baf29d88af2b","ml-papers-of-the-week-github-research-desk-en","ML Papers of the Week Turns GitHub Into a Research Desk","2026-03-27T01:11:39.480259+00:00",{"id":87,"slug":88,"title":89,"created_at":90},"87897a94-8065-4464-a016-1f23e89e17cc","ai-ml-conferences-to-watch-in-2026-en","AI\u002FML Conferences to Watch in 2026","2026-03-27T01:51:54.184108+00:00",{"id":92,"slug":93,"title":94,"created_at":95},"6f1987cf-25f3-47a4-b3e6-db0997695be8","openclaw-agents-manipulated-self-sabotage-en","OpenClaw Agents Can Be Manipulated Into Failure","2026-03-28T03:03:18.899465+00:00",{"id":97,"slug":98,"title":99,"created_at":100},"a53571ad-735a-4178-9f93-cb09b699d99c","vega-driving-language-instructions-en","Vega: Driving with Natural Language Instructions","2026-03-28T14:54:04.698882+00:00",{"id":102,"slug":103,"title":104,"created_at":105},"a34581d6-f36e-46da-88bb-582fb3e7425c","personalizing-autonomous-driving-styles-en","Drive My Way: Personalizing Autonomous Driving Styles","2026-03-28T14:54:26.148181+00:00",{"id":107,"slug":108,"title":109,"created_at":110},"2bc1ad7f-26ce-4f02-9885-803b35fd229d","training-knowledge-bases-writeback-rag-en","Training Knowledge Bases with WriteBack-RAG","2026-03-28T14:54:45.643433+00:00",{"id":112,"slug":113,"title":114,"created_at":115},"71adc507-3c54-4605-bbe2-c966acd6187e","packforcing-long-video-generation-en","PackForcing: Efficient Long-Video Generation Method","2026-03-28T14:55:02.646943+00:00",{"id":117,"slug":118,"title":119,"created_at":120},"675942ef-b9ec-4c5f-a997-381250b6eacb","pixelsmile-facial-expression-editing-en","PixelSmile Framework Enhances Facial Expression Editing","2026-03-28T14:55:20.633463+00:00",{"id":122,"slug":123,"title":124,"created_at":125},"6954fa2b-8b66-4839-884b-e46f89fa1bc3","adaptive-block-scaled-data-types-en","IF4: Smarter 4-Bit Quantization That Adapts to Your Data","2026-03-31T06:00:36.65963+00:00"]