Trusted open resilience software
A clearer front door for preparedness, mapping, and response products.
OpenCorex brings project tracks, contribution routes, and documentation into one durable public experience so visitors can understand the work before they try to change it.
Platform snapshot
Shared content, reusable sections, and calmer hierarchy across the whole site.
0
project tracks
Defined initiatives with audiences, stages, and clear operating focus.
5
working groups
Cross-functional lanes that keep design, delivery, and support visible.
5
documentation lanes
Shared references for content, design, release, and support quality.
How the hub works
Visitors can move from discovery into contribution without losing context.
0
project tracks
Defined initiatives with audiences, stages, and clear operating focus.
5
working groups
Cross-functional lanes that keep design, delivery, and support visible.
5
documentation lanes
Shared references for content, design, release, and support quality.
6
contribution paths
Clear entry points for engineering, writing, research, and community work.
Platform posture
Clear public explanations, strong defaults, and less dependency on live external data.
The site now behaves more like a product handbook than a placeholder landing page. Each section is there to answer a practical question: what OpenCorex builds, how the work is organized, and where contributors can help.
Principle
Field-ready by default
We design for low-bandwidth conditions, high-stress moments, and teams that need clarity faster than they need novelty.
Principle
Built in the open
Plans, design decisions, and content structures stay visible so contributors can understand context before they write a single line.
Principle
Modular enough to scale
Each track is shaped as a reusable capability, making it easier to ship lightweight pilots without creating long-term maintenance debt.
Flagship tracks
Platform tracks explained through audience, stage, and delivery priorities.
Instead of generic placeholders, the public story now stays close to the actual platform lanes and the people those lanes are designed to support.
Delivery rhythm
Listen first
Every track begins with real operational friction, not abstract feature collecting. We document the problem before we brand the solution.
Ship the smallest durable version
We favor scoped releases with clear ownership, usable defaults, and obvious next steps over oversized launches that are difficult to sustain.
Refine in public
Feedback loops stay visible so design, content, and engineering decisions can evolve with shared context instead of hidden handoffs.
Working groups
Cross-functional ownership is visible, not hidden inside the codebase.
Platform Experience
productShapes the public experience, information architecture, and how visitors move from interest to action.
Looking for: Product writers, UX thinkers, and front-end contributors.
Data and Delivery Systems
engineeringOwns the technical patterns that keep project tracks coherent, maintainable, and easy to extend.
Looking for: TypeScript contributors, maintainers, and systems-minded reviewers.
Design Language
designMaintains visual consistency across cards, sections, responsive layouts, and supporting documentation.
Looking for: UI designers, accessibility reviewers, and design-system contributors.
Next steps
Move from the high-level story into the practical work without a dead end.
Browse the tracks, review the docs, or jump into contribution guidance. Every route now points back into the same shared platform narrative.
