This has been a problem before – underspecified projects, specifications going out of sync with the first line of code. We've just amplified it now.

A lot of people (myself included) have tried to maintain good specifications in markdown to give LLMs and humans maximal context. But this is still walls of text that poison anyone's context, regardless of their artificiality.

So I built a way to model knowledge as a graph that both people and LLMs can consume progressively – by navigating the graph or searching for specific connectivity patterns rather than ingesting everything at once.

At its core it's an open specification for layers that add progressively more semantic value: starting with prose, growing into terminology, tasks, concepts, API surfaces, and structured plans.

The most critical component is a layer that maps artifacts (such as code) to the knowledge model with good enough precision to track drift and coverage automatically.

Comments URL: https://news.ycombinator.com/item?id=47531025

Points: 3

# Comments: 0

By introducing progressive semantically enriching layers (starting with prose, reasoning and terminology and going all the way into specifying interaction surfaces), we can reduce the dark matter between spec and code, make code more disposable – if your semantics live in the spec layer rather than the implementation, you can throw away and regenerate the implementation without losing understanding – and, critically, give LLMs a way to navigate a graph of knowledge instead of gobbling up walls of text.

https://clayers.com -- https://github.com/CognitiveLayers/clayers

Comments URL: https://news.ycombinator.com/item?id=46947536

Points: 9

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46384643

Points: 1

# Comments: 1

I also own section174.com and sec174.com

Would these help with visibility?

Few more cases are being worked on!

Comments URL: https://news.ycombinator.com/item?id=41717024

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=41141764

Points: 1

# Comments: 0

Yet to explore the new capabilities!

I think I can see some parallels to Supabase's wrappers project.

Keep up the good work!

At Omnigres, our north star is to enable developers to laser-focus on business needs instead of fighting technological challenges.

We're fighting the complexity and inefficiencies of contemporary stacks by removing them instead of hiding them.

At the core, we are turning Postgres into an Application Runtime. Why? Because we believe that code and data are inseparable in pretty much all of the line-of-business application systems. Turns out, when done this way, applications work a lot faster, require a lot less maintenance and are simply easier to write.

Our foundation is open source and is available at https://github.com/omnigres/omnigres

We're backed by some great early-stage VCs and looking to onboard people who can move quickly, learn on the go and maintain the focus on the goals. Another way to look at it: we want to meet other pragmatic idealists.

You can apply here https://wellfound.com/jobs/2832133-founding-engineer or email founders@omnigres.com

We'll see what the future will bring, as the real edge of computing is in user's hands.

There's a keen interest to get there for Omnigres applications, but the shape of that is still somewhat vague.