Crosswalk

Inspiration

Every physical product is full of solved problems in disguise. A drone housing that won't crack in the cold, a battery pack that needs to shed heat, a surface that has to resist fouling — each of these is a function, and somewhere in the research literature, someone has already solved that exact function. The catch is that they usually solved it for a completely different product, in a completely different field, using vocabulary an engineer in your field would never think to search.

This isn't a hypothetical. It's the entire premise behind TRIZ and biomimicry — two well-established innovation methodologies built on the same idea: abstract your problem to its underlying function, then look at what other fields have already done to solve that function. Speedo's shark-skin swimsuits, kingfisher-inspired train noses, lotus-leaf self-cleaning surfaces — these are all famous examples of exactly this kind of cross-domain transfer. What struck us is that this methodology has always been done by hand, by a person with the right cross-disciplinary intuition, or by expensive technology-scouting consultants doing it slowly for one client at a time. Nobody had automated it at the scale of an entire product, across the entire research graph, computing distance across fields rather than just similarity.

We also cared about building something that used Jac's actual differentiator — object-spatial programming — for a reason, not as a costume on top of an idea that would work just as well as a normal app. A multi-hop traversal from a concrete feature to a foreign-field solution, crossing vocabulary boundaries a step at a time, is a walker problem in the truest sense: it's a path, not a lookup.

What it does

You give Crosswalk a real product — its name and description, or pasted spec text. It:

1. Decomposes the product into a graph of components and the functions each one needs to serve.
2. Abstracts concrete features into domain-neutral functional descriptions — "won't crack in the cold" becomes "impact resistance at low temperature," which becomes "energy absorption in brittle materials."
3. Walks outward across OpenAlex's ~250 million-work research graph, following functional relevance rather than keyword or field similarity, deliberately favoring results that are near in function, far in field.
4. Judges and verifies each candidate before showing it, translating the finding back into the team's own language.
5. Shows its work — the exact hop path that got from your product to the answer, so a non-obvious connection is legible and trustworthy instead of a black-box suggestion.

Before showing anything novel, Crosswalk proves itself on a known transfer — pointing it at swimsuit drag and watching it independently rediscover shark-skin denticles — so the mechanism is validated before we ask anyone to trust an unfamiliar result.

How we built it

Crosswalk is built on Jac, using object-spatial programming as the core architecture rather than a conventional database-plus-API stack:

• Nodes and edges model the actual domain: Product, Component, Function, ResearchWork, and Field, connected by relationships like requires_function, abstracts_to, and serves_function.
• Walkers do the traversal work that a flat query can't: a decomposition walker builds the initial graph, an abstraction walker climbs from concrete feature to general principle, and a discovery walker fans out in parallel across every function node to search OpenAlex — mirroring the fact that no human could manually monitor the literature for forty subsystems of a product at once.
• by llm() is used at exactly the points that need judgment rather than computation: decomposing a product description into structured components and functions, making the abstraction leap from a concrete feature to its general principle, and judging/translating each candidate research result.
• Ranking is never relevance alone. The core scoring signal is functional_relevance × field_distance, computed using OpenAlex's own concept/field hierarchy — this is the single design decision that separates Crosswalk from a semantic search box, which would just return the nearest (and most obvious) neighbor.
• OpenAlex is our data backbone — free, open, and already structured as a graph (works, concepts, citations), which meant we were traversing an existing graph rather than building one from scratch.

Challenges we ran into

The biggest engineering challenge wasn't the graph model — it was cost and latency. Our first pass called an LLM once per candidate paper, per function, across multiple abstraction hops, and the number of API calls exploded combinatorially before we'd shown a single result. We restructured the pipeline around a simple principle: spend LLM calls only on survivors. Cheap, non-LLM filtering (concept overlap and field distance, computed directly from OpenAlex's metadata) narrows a pool of candidates down to a handful before any model call touches them. We also batched what had been many small per-paper judgment calls into single structured calls returning a list of judgments, and reserved a genuinely independent verification pass only for the results we were actually going to display, rather than re-verifying everything that survived the first filter. That took us from well over a hundred calls per demo run down to roughly a handful.

The other real challenge was making sure the pipeline stayed genuinely general rather than quietly hardcoded to our demo products. It's tempting, under time pressure, to special-case the products you've tested — we made a point of keeping the decomposition, abstraction, and discovery logic identical whether it's running fresh on arbitrary input or being served from a cached fixture for demo reliability, and validated that by running the full live pipeline against a product nobody on the team had pre-tuned for.

What we learned

• Object-spatial programming maps unusually well onto problems that are genuinely about paths, not lookups — this project would have been a much weaker "wrapped API call" if we'd tried to build it as a normal retrieval app.
• Field-distance scoring — deliberately ranking away from the nearest, most obvious result — is a small design decision with an outsized effect on whether a system feels like search or like discovery.
• Structured output and batching aren't just efficiency tricks; they're what makes a multi-agent pipeline demoable at all under real time and cost constraints.
• Proving a mechanism on a known example before showing a novel one is a strong pattern well beyond this project — it's a general way to make an otherwise-unverifiable "trust me, this is non-obvious" claim into something an audience can actually evaluate.

What's next

• Continuous monitoring — re-walking the graph as new grants and preprints appear, and alerting a team when something new becomes relevant to a function they've already mapped.
• A portfolio mode — ingesting a company's entire product line to run discovery across everything they make, not one product at a time.
• A freedom-to-operate mode — flipping the same graph to surface patent white space instead of solutions.
• Bringing grants and patents onto the same graph as OpenAlex, so a function node can fan out not just to a paper, but to the lab that's funded to work on it and the startup already commercializing it — turning a literature tool into a technology-scouting and partnership engine.

Built With

• jaclang