Introducing RVA: One Visual Asset, Any Screen Size

ROBIUL HOQUE — Fri, 09 Oct 2026 11:16:57 +0000

The problem with responsive images

Responsive design has come a long way.

We have CSS Grid, Flexbox, container queries, responsive typography, and increasingly sophisticated layout systems.

But there's one area where responsiveness still often means maintaining multiple versions of the same thing: visual assets.

Consider a promotional banner containing:

A background gradient or photograph
A product image
A headline and supporting text
A brand logo
A call-to-action button

The design needs to appear on a desktop website, a mobile landing page, a social media post, and perhaps inside a native application.

Typically, a designer creates separate compositions for each target aspect ratio.

A wide banner might work perfectly at 16:9, but crop the product at 9:16. Text that looks balanced on desktop might overlap the subject on mobile.

Simply resizing the image doesn't solve the problem.

CSS can reposition elements when those elements exist independently in the DOM. But once the entire composition is flattened into a PNG, JPEG, or WebP, those relationships are lost.

What if the asset itself understood how to adapt?

That's the question that led us to build RVA.

Meet RVA — Responsive Visual Asset

RVA is an open-source, self-contained visual asset format and composition model developed at Airovo Technologies.

Instead of treating a visual as one flattened image, RVA packages the elements of a composition together with the information needed to arrange them at different rendering dimensions.

A single .rva file can contain:

Raster and vector resources
Text elements
Groups and masks
Layout constraints
Aspect-ratio-specific compositions
Visibility, cropping, and positioning rules
Fallback rendering information

The goal is straightforward:

Create a visual composition once, define how it should behave, and let the rendering engine resolve the appropriate layout.

RVA is not intended to replace PNG, JPEG, WebP, SVG, or AVIF.

Those formats are excellent at what they do.

RVA addresses a different problem: preserving the structure and responsive behavior of a multi-element visual composition.

See it in action

One visual asset adapting to different aspect ratios.

Try the interactive RVA demo →

The demonstration illustrates how a composition can rearrange its elements as the available rendering dimensions change.

Rather than stretching or cropping an entire flattened image, RVA resolves the positions and dimensions of individual elements according to the asset's authored rules.

How RVA works

At a high level, RVA separates the definition of a visual composition from its final rendering.

The processing pipeline looks like this:

.rva asset
    |
    v
Parse and validate
    |
    v
Resolve layout
(width, height, environment)
    |
    v
ResolvedScene
    |
    v
Platform renderer
    |
    v
Final visual output

The important component is the resolver.

It determines what should appear, where it should appear, and how elements should relate to each other for a given viewport.

The platform renderer then draws the resolved composition using its native graphics capabilities.

1. Structured elements

An RVA composition contains independent visual elements rather than only a flattened bitmap.

For example, a product advertisement might include a product photograph, headline, logo, and background as separate resources.

Each element can have its own positioning, visibility, priority, and cropping behavior.

This allows the composition to change without losing the identity of its constituent elements.

2. Responsive topologies

Different aspect ratios sometimes require genuinely different compositions.

A desktop layout might place text on the left and a product image on the right.

A portrait layout might place the product above the headline.

RVA supports alternative composition topologies selected according to aspect-ratio ranges.

The same underlying resources can therefore participate in multiple layouts.

3. Layout constraints

RVA supports authored relationships between elements, including alignment, spacing, containment, and overlap avoidance.

These constraints help the resolver produce layouts that respect the designer's intended relationships.

Not every layout can be made responsive automatically. The quality of the result still depends on the authored structure and constraints.

RVA provides the mechanism for expressing those decisions and resolving them consistently.

Built with Rust, designed for multiple platforms

We chose Rust for RVA's reference core because we wanted a portable implementation with explicit control over memory, parsing, and execution behavior.

The core handles:

Binary container parsing
Asset validation
Topology selection
Constraint resolution
Layout computation
Resource access

The same core is exposed through WebAssembly and native bindings.

Our architecture follows one important principle:

The core decides what to draw. The platform decides how to draw it.

This keeps the responsive layout semantics independent of a particular UI framework or graphics API.

Cross-platform support

The open-source repository includes packages and adapters for several environments:

Environment	Integration
Rust	`rva-core`
Browser	`@airovo/rva-web`
Node.js	`@airovo/rva-node`
React	`@airovo/rva-react`
Vue	`@airovo/rva-vue`
Svelte	`@airovo/rva-svelte`
React Native	`@airovo/rva-react-native`
iOS / Swift	Swift Package
Android / Kotlin	Native Android library
Flutter	`rva_flutter`

The repository also includes a CLI, HTTP server, C ABI, and conformance tooling.

Getting started

For JavaScript developers, RVA provides packages published under the @airovo namespace.

For example, install the browser integration:

npm install @airovo/rva-web

Or the React integration:

npm install @airovo/rva-react

For Rust developers:

cargo add rva-core

You can also install the command-line tool:

cargo install rva-cli

The CLI supports validation, inspection, rendering, packaging, and unpacking of RVA assets.

For example, from the repository workspace:

cargo run -p rva-cli -- inspect \
  --width 1280 \
  --height 720

To render an asset:

cargo run -p rva-cli -- render \
  --width 1280 \
  --height 720 \
  --out out/hero.png

And to package an RVA asset:

cargo run -p rva-cli -- pack \
  --out hero.rva \
  --optimize

For complete installation instructions and platform-specific examples, see the GitHub repository.

Consistent layout resolution across runtimes

Cross-platform rendering introduces an interesting challenge.

Different platforms have different graphics libraries, font engines, and rendering behaviors.

If each platform independently decides how to lay out an RVA composition, the results can drift.

To address this, RVA uses a shared resolution model.

Given the same asset, viewport, specification version, and resolver profile, the core is designed to produce the same ResolvedScene.

Same asset
+ Same viewport
+ Same resolver profile
        |
        v
Same resolved scene

This is a layout-level guarantee, not a promise of pixel-identical rendering on every platform.

Actual rasterized pixels can differ between graphics backends.

The repository includes cross-runtime conformance tests comparing the native Rust implementation, WebAssembly, and C ABI output.

It also includes adversarial fixtures to test layout boundaries, malformed resources, fallback behavior, and other edge cases.

For us, this was an important part of building RVA as a portable format rather than a renderer tied to one platform.

What RVA is — and what it isn't

It's worth clarifying a few things.

RVA is not another image compression codec.

It doesn't aim to outperform AVIF or WebP at compressing photographs.

RVA is not a replacement for CSS.

If you're building a responsive web interface with ordinary HTML elements, CSS remains the natural solution.

RVA is not an automatic design generator.

It doesn't magically turn every existing image into a well-designed responsive composition.

RVA is useful when a visual needs to be distributed as a single asset while preserving its internal structure and responsive behavior.

Potential applications include advertising creatives, product banners, promotional artwork, cross-platform branded visuals, and embedded application graphics.

These are areas we're interested in exploring with developers and designers.

Why we're open-sourcing RVA

We believe a visual asset format is more useful when its behavior is transparent and its implementation is accessible.

A format intended to work across platforms shouldn't depend entirely on a single proprietary renderer.

That's why we've made the RVA reference implementation, specification work, adapters, and developer tooling available on GitHub under the MIT license.

The repository includes the Rust core, WebAssembly bindings, native integration layers, examples, and testing infrastructure.

The format and implementation will continue to evolve. We're particularly interested in feedback on interoperability, authoring workflows, responsive layout semantics, and practical integration challenges.

What's next?

Now that RVA is publicly available, our focus is on making it easier for developers to experiment with the format and explore real-world use cases.

We're interested in questions such as:

Where would a self-contained responsive visual asset be useful?
What integrations would make RVA easier to adopt?
What limitations should the format address?
How should authoring tools expose responsive composition rules to designers?

We don't expect RVA to replace existing image formats.

We see it as a complementary approach for a specific class of visual content that needs more than resizing and cropping.

And we'd like to find out how useful that approach can become.

Explore RVA

Interactive demo: https://rva.airovo.tech/

GitHub repository: https://github.com/airovo/rva

Documentation: https://github.com/airovo/rva/tree/main/docs

License: MIT

RVA is developed by Airovo Technologies, an independent software product and engineering company.

If you're working on responsive graphics, rendering engines, developer tooling, or visual asset pipelines, we'd love to hear your thoughts.

What do you think about making responsiveness part of the visual asset itself?

Thanks for reading! If you find RVA interesting, explore the repository, try the interactive demo, or open a GitHub issue to share your feedback.

How We Used RAG to Power an AI-First Internal Tool Builder

ROBIUL HOQUE — Sun, 31 Aug 2025 16:57:20 +0000

At PromptGrid, we’re building an AI-first internal tool builder where teams can connect their data sources (databases, spreadsheets, APIs, metrics, etc.) and instantly create apps and dashboards.

The magic moment is when a customer turns on AI Mode and simply asks:

Create a dashboard that shows my weekly sales trend and top-performing products.

And PromptGrid just… builds it.

But getting here wasn’t straightforward.

The Challenge: Context Overload

When customers connect their data sources, their data must remain private. We can’t send sensitive records to AI, yet the AI still needs to understand:

What resources are available
How widgets and layouts should be structured
The rules for different types of sources (database vs. sheet vs. API)

Our first instinct was to stuff all this context into the AI prompt. But we quickly ran into limits:

Context grows as customers add more sources
Prompts become too large and too expensive
AI struggles with noise, lowering accuracy

Clearly, this wasn’t scalable.

The Breakthrough: Retrieval-Augmented Generation (RAG)

Instead of sending everything to the model, we moved to a retrieval-based approach.

Here’s the high-level flow:

Break down metadata (schemas, layouts, resource rules) into smaller, reusable knowledge units
Index them for semantic search
On every AI request, retrieve only the relevant pieces based on the user’s query
Inject those into the prompt alongside the request

This way, the AI sees only the context it needs to generate the right app or dashboard — no more, no less.

Why RAG Made the Difference

Scalable → Adding new data sources doesn’t explode prompt size
Efficient → Smaller prompts mean faster responses and lower costs
Accurate → AI gets only the most relevant context instead of drowning in noise
Privacy-friendly → No raw customer data is ever shared with the model

The Impact 🚀

After adopting this approach:

AI-generated dashboards became more relevant and precise
Customers went from connection → usable dashboards in seconds
Prompt sizes shrank dramatically, making the system faster and cheaper to run

For our users, the experience feels like:

"I just describe what I want, and my dashboard builds itself."
"It feels like having a data engineer on demand — without writing a single line of SQL."

Lessons for Other Builders

If you’re designing AI-first products:

Don’t overload prompts — retrieval beats brute force
Think in modular context — smaller knowledge units improve precision
Privacy by design — keep customer data safe while still enabling intelligence

Where We’re Headed Next

We see RAG as the foundation, not the finish line. With this in place, we’re exploring:

Smarter ranking to surface the most relevant context
Multi-step AI builders that remember ongoing conversations
Shareable AI-generated modules for teams

Our vision: make building internal tools as natural as having a conversation with your data.

We’re building PromptGrid to make internal tools AI-first. Try it free at https://promptgrid.app/.

DEV Community: ROBIUL HOQUE