What Distributed Systems work at GIKSN looks like
GIKSN Research is a community-first lab where distributed systems work sits alongside AI, Deeptech and Hardware. This is the systems-side view: why the failure model comes first, what a systems paper on the archive looks like and how the sector supports the rest of the work.
The systems papers that survive get to state their failure model on the first page. The systems papers that do not survive tend to bury it. GIKSN Research is a lab where distributed systems work goes into the archive with its assumptions in the open: crash-stop or Byzantine, synchronous or asynchronous, what breaks under partition, what does not. That is the entry price. Everything else follows from it.
What we treat as our sector
Consensus, storage, coordination, replication, protocols, scheduling and streaming. The plumbing that keeps working when parts fail. We include operational writing here too, because the runbook is often the paper. A protocol without an operator manual is a whiteboard, not a system.
What a paper looks like
A DS paper on GIKSN opens with a failure model and a workload. It names the property being traded, because you never get all of them, and it says which one it is willing to lose. Message complexity per operation is called out honestly. Correctness arguments cite the results they lean on. If a design is only faster than the baseline on read-heavy workloads that is stated on the first page, not the last.
Why the open archive fits
Systems knowledge tends to live in postmortem blog posts and internal wikis. Both are useful and neither is a citable record. GIKSN gives systems research a stable home where the reasoning is visible, the discussion thread stays open and the authors are credited by name. Rejected designs stay in the archive because the reasoning matters even when the design failed.
The cross-sector view
A distributed system that serves an AI workload has to think about batch dynamics that the model paper never mentions. A hardware paper that assumes a topology needs a systems paper to explain why the topology is safe under load. A deeptech result that runs on a cluster is a systems problem when it scales. The archive is one comment floor across four sectors so that these arguments happen in public rather than in Slack.
What we ship
Rinne, the first shipped tool, is not a distributed system. Systems products from the bench will be. When they arrive they will land on the products page with formal verification status where applicable, an operator runbook and a paper that argues for the design decisions we made.
Reading and contributing
Papers are open. Discussion is open. Contribution is gated because sustained systems work requires it. Applications land through the About page, and accepted contributors join private working channels on Telegram alongside the public read-only ones.