{{ heroTitle }}
{{ heroBody }}
A mind that scales is arriving before a system that shares.
Machine intelligence is becoming the productive force of the century. It already models, writes, decides and builds; it is heading for a scale no institution can supervise line by line.
Every earlier leap in production was absorbed by the organizations that already existed, and each one concentrated the result. Applied to general intelligence, that pattern ends with the most capable thing humanity has ever produced held by the fewest hands that ever held one — not through malice, but because nobody built the alternative in time.
The answer is not slower intelligence. It is a system designed for it: work cut small enough that anyone can take a piece and finish it, decisions recorded where anyone can audit them, and resources following what was delivered instead of what position someone holds.
In that system intelligence is not a tool bolted onto an organization — it is integrated with life, work and the resources both depend on, symbiotic with them, and what it amplifies is the capacity people already have and cannot currently reach.
That system is what Drayker is designing, in public, and this site is careful about the distance between what is written and what runs.
Four layers that add up to one intelligence.
Drayker is a collective intelligence integrated with artificial intelligence — people, teams and agents thinking and delivering inside the same structure, on the same terms, neither one supervising the other. That is the thing being built. The four layers are what it takes for it to exist.
Read them as one sentence. DFM is the method, in its versions for organization, engineering, architecture and A.I. agents; Dk is the technological system that method is being used to design — kernel, network, cryptography, identity, intelligence, devices; organization and resources is how decisions and means are held distributed, transparent and intelligent; and the transition is the part that is real today — the DAF, the GitHub organization, the public sites, whatever tool works — building toward a platform of its own. The method is in use. The rest is architecture, and the transition is where it becomes something.
Model a problem, break it into small functions, distribute them worldwide through decentralized peer review. A person and an agent claim a function on identical terms — that is what makes human and machine intelligence one workforce instead of two.
The whole technological system as one distributed architecture: the kernel and its base structure, the network, cryptography, identity, intelligence and the devices that attach to it. A substrate meant to be inhabited rather than operated, where an agent, a person and a machine hold the same system and none of them owns it.
Decisions and means held distributed, transparent and intelligent: autonomous units, weight that accumulates from delivered work rather than appointment, and a unit of value meant to carry its own rules. The specifications this layer needs are the emptiest pages in the system.
The layer that is actually being built, with the resources that exist: the DAF, the organization running on GitHub, the public sites and knowledge base, and whatever tool serves best until an evolutionary platform of its own can replace it. Emergent work belongs here before it has a home.
Twenty parts, and the layer each one answers for.
Every part sits in exactly one layer, and the words beside it are the standing its own repository declares — not a plan, not a promise. Open any of them.
Pick a part. See what has to be written before it can exist.
These chains are computed from the dependencies each repository declares in its own component contract. A part appears as a blocker when it is not running yet, and the gap under it is the one its own page states — so every line here is work somebody could take.
Choose any part above. Most chains end at the same few unwritten documents, which is the most useful thing this site can tell you.
{{ blkOwn }}
Nothing upstream is holding this one back. What is missing is inside it, and its own page says what.
Research and documentation remain active, and voluntary contributions are open. Large-scale implementation depends on sufficient funding. Participation does not imply compensation, and the concepts described here are not claims of an operating global system, financial product or medical service.
Every page here separates what is written from what is running. Where a source is thin, the page says so.
Humanity has immense latent capacity. We exist to create the conditions — of organization and action — that unlock it.
It goes further with money, and it goes further with people.
Funding, research collaboration, infrastructure and compute, institutional partnership. What is written can keep being written on volunteer time; implementation at scale cannot.
This site explains the system; the volunteers portal is where it gets built. Every project, what each one is missing, the contribution process, and a guided way in that ends with a track and a first step.
We can solve problems we believe are impossible.
Drayker starts from a conviction: we can do more with less, evolve faster, and solve problems we have given up on.
None of that is a question of talent or capital. It is a question of conditions — the conditions of organization and of action. Most human effort is lost in coordination: in hierarchies that filter information, in work that is never documented, in decisions nobody can trace, in problems too large for any single team to hold.
Drayker exists to create those conditions — so civilization can build infrastructure, scale up, and act at a level it never could before.
So we started with the method instead of the product. First a specification for collaboration — DFM — which breaks any issue into small individual functions, so that thousands of strangers can work on one thing without a manager in the middle.
Then the systems that method makes possible: a distributed kernel, a network of its own, an identity that belongs to the person, and a federation designed to hold resources without a head office.
We are writing this for the era that is arriving, not the one we grew up in. When intelligence stops being scarce, the question is no longer who can think — it is how thinking, work and resources are held together, and by whom. A system built for that era does not place intelligence above life; it integrates intelligence with life, with work, and with the resources both depend on, and what grows is the capacity people already have and cannot currently reach.
We develop human, collective and artificial intelligence to reach further and see further. We do this for people — for each person. The boundless evolution of humanity is the end; intelligence is the means.
A problem, cut small enough for the world to solve.
Distributed function modularization is the collaboration paradigm behind every Drayker project. It adapts to different domains, but the logic is always the same: model, fragment, distribute, review.
Five moves that remove the coordinator.
This is the paradigm, not a tool you install — it describes how an issue becomes finishable work for people who have never met. The council and validation layers it describes are designed, not in place. What carries the method today is GitHub, and that process is written out below.
{{ dfmBody }}
{{ dfmNote }}
Self-assessed, validated, re-evaluated.
The protocol ensures that every paper is self-assessed, validated and re-evaluated. Validation walks alongside development — ideas are discussed with communities and councils, then shaped into a detailed, widely revised paper that passes through the DAOs and councils before adoption.
All ideas, goals and purposes must be in line with Drayker.
The designed path takes a paper from an issue thread, through discussion with communities and councils, to a recorded validation status. DFMP-000 — the paper that should specify that path — has not been written yet, which is why the process below is the one actually in use.
The part you can use this afternoon.
No separate platform, no review branch, no gatekeeper. Everything runs on the ordinary public Git flow, in the open, in the repository the work belongs to.
{{ dfmIssueNote }}
A kernel for the things nobody can build alone.
Dk is the system Drayker is designing: intelligence, organization and computing as one distributed architecture — secure, fail-safe and self-improving by construction, and meant to be inhabited rather than operated. The point is not a smarter service. It is a substrate where intelligence sits inside daily life and work instead of above them. It is documented and argued over in the open; none of it is running yet.
The same kernel, at three distances from you.
Dk is not one intelligence in one place. It is designed as a personal agent, specialised local agents, and the collective intelligence that federated learning from both is meant to add up to. Learning travels upward; personal context does not.
The collective intelligence: the layer that concentrates the federated learning of every local and personal Dk. Nobody logs into it — it is what the others amount to together, and the reason a lesson learned once does not have to be learned again everywhere.
Each member's own agent, bound to their UID. It works in personal context — what someone is doing, what they are trying to understand about themselves, what to give the day to. It contributes learning upward without handing over the context that produced it.
Agents specialised in a specific project, area or function — the non-deterministic work that cannot be written as a fixed procedure. A local Dk knows its domain deeply and nothing else, and sends what it learns up the same way a personal one does.
None of the three scales is implemented, and neither are three of the five parts they stand on. The architecture is what is open for argument — which is a better thing to hand someone than a finished system nobody can change.
A general intelligence is the goal, not the claim: BSDK and DFM are the architecture it is being designed on.
When machines carry the repetitive load, humans are free to do what matters. There will be no shortage of things to do.
Public infrastructure, part by part.
Each part below is meant to be public, replaceable and owned by nobody \u2014 the protocol, the kernel and the network, the federation, and the applications they are meant to carry. Most of them are still an argument rather than a program, and every page says which.
Nothing here answers to {{ ptMissingKey }}.
The part may have been renamed, or the page for it has not been written yet. Every part that does have one is a click away.
{{ ptName }}
{{ ptClaim }}
{{ ptToday }}
{{ ptShift }}
{{ ptFeel }}
{{ ptStake }}
{{ ptLayerLine }}
Nothing is declared underneath it yet.
Nothing declares a dependency on it yet.
This page makes the case. The portal holds the evidence.
Nothing below is repeated here. Each link opens the section of the drayker.org page for {{ ptName }} that answers exactly that question — architecture, declared scope, or what is still missing.
The parts are easier to read in order: the method first, then what it is being used to design, then how it would be governed, then what all of it is for.
An organization designed to outgrow whoever started it.
Drayker is in its founding phase. A transitional administration keeps the repositories, the domains and the daily decisions moving, and the structures meant to replace it — the DAF and its councils — are designed rather than running. Until they exist, Git and GitHub carry the accountability: every change, every discussion and every decision is public and attributable.
A founding phase, said plainly.
Appearance
Choose how the portal renders for you. The choice is stored on this device and applies to drayker.org and drayker.com alike.
Linking an autonomous unit — how it is meant to work.
In the designed federation, a person, a team or an initiative can organize as an autonomous unit and link it to the DAF, accumulating federative weight and voting power from delivered work rather than from appointment.
None of that mechanism is specified yet — no contract, no point calculation, no voting procedure. Until it is, a new initiative is proposed the way everything else is: in a public issue. Support is requested only where there is no other alternative; the main projects come first.
Everything you need to start today.
One portal for the whole collaboration: what each project is for, what it is missing, what is open on GitHub right now, which track fits you, and exactly how work travels from an issue to a merge.
Three steps, in any order.
You do not need to know the whole system to contribute to it — that is the entire point of the protocol.
The people currently building it.
Read live from the commit history. Nothing here is anonymous by default: your work stays attributed in the history of the repository it landed in.
How work travels here.
Issue → claim → fork and branch → pull request to master → checks and discussion → merge. Six steps, written out with the exact commands.
Seven ways in.
Code is one of them. Research, review and translation carry the same weight — a paper nobody reviewed is not legitimated, and a paper nobody translated does not reach the people it was written for.
Every project, and what it is for.
{{ projNote }}
Named in the architecture, no repository yet.
These are parts the system is designed around and nobody has written down. There is nothing to fork — which is exactly why the first page, the first model or the first honest objection counts as much here as code does anywhere else.
Nothing here answers to {{ missingKey }}.
The project may have been renamed, or the page for it has not been written yet — writing one is itself an open function. Every project that does have a page is one click away.
{{ pd.name }}
{{ pd.tagline }}
{{ pdPlain }}
That sentence is the whole thing, without jargon. Everything below is optional — fold a level away with the buttons above if you have read enough.
{{ pd.vision }}
{{ pd.problem }}
{{ pd.role }}
{{ pd.relations }}
{{ pd.state }}
None yet. This part is named in the architecture and written nowhere — the first document about it becomes its source.
Its neighbours, read from the declared dependencies rather than drawn by hand. On the left, what this part cannot be specified without. On the right, what cannot be specified without it. Any of them opens.
Nothing declares a dependency in either direction yet. For a part of a system that is meant to interlock, that is itself worth arguing about.
{{ pcProblem }}
Every repository in the organization publishes this contract, and a pull request that breaks it does not pass. It states what the component covers, what it explicitly does not, and what evidence stands behind the difference.
Nothing in the ecosystem is declared as a prerequisite for this one.
Every repository in the organization declares its own boundaries. This part has no repository to declare them in.
A contract names the problem, what is in scope, what is explicitly out of scope, what depends on it, what evidence exists and what could be misread — and a pull request that breaks it does not pass. Writing the first document about this part is what makes one possible, and the schema tells you exactly which questions it has to answer.
COMPONENT.SCHEMA.JSON →No open issue is listed for this repository right now. Open one: a well-modelled issue is a contribution in itself, and it is how every function on the board started.
The twenty pages have a suggested order — the method first, then what it is being used to design, then how that would be governed, then the public surfaces. You can leave the trail at any point.
Take a function. Any size.
Every issue is fragmented into functions small enough for one person to finish. Pick one, claim it in the thread, deliver it as a pull request. What is here is exactly what is open on GitHub — no more, and never a placeholder.
{{ fnEmptyLabel }}
From issue thread to master.
The same six steps for every function, in every repository, whatever your track. Nobody assigns work, and nothing is merged without the discussion being visible.
Reading the board.
Labels are the whole coordination layer. If an issue is unlabelled, labelling it correctly is already a contribution.
You do not have to ask how this works.
Three files govern every repository, and they are versioned like everything else. If one of them is wrong, correcting it is a contribution like any other.
Still not sure where you fit?
Tell us what you are good at and what you care about. We will point you at functions that match — and nothing stops you from claiming one today anyway.
Not a wiki. The brain of the system.
A wiki is pages someone remembered to write. Dknowledger is meant to be a network: requirements, the motions that answer them, the decisions that changed them and the evidence behind each one, connected to their sources and carrying how much weight each deserves. Memory that can be followed, not information that can be stored — and the place the system thinks from, not a copy of thinking kept somewhere else.
Its first versions exist to get people into the ecosystem. Over time it is meant to become the structured base for Dk's data, sensors, files, oracles, processes and ontologies across public, federated and private layers. The repository states that as a direction, not as a running system — and this page keeps the two apart.
Six kinds of node, and the edges that make them a brain.
Only one of these is machine-readable today — the component contract. The rest exist as prose, threads and files. Naming them as node types is what would let a question be answered by the base instead of by a person who happens to remember.
How much weight a node has earned — never how important it is.
A level is a statement about evidence, the same rule the repository contracts already follow. Nothing in the repository specifies this scale yet: it is the proposal on the table, and writing it properly is itself an open piece of work.
Sixteen papers exist as titles. That is the opening.
Read with the level attached. Filter by it if you are looking for something specific — the empty ones are where a first contribution has the most leverage.
Nothing in the base sits at that level right now.
Writing down where a paper no longer matches reality is a contribution.
That sentence is in the repository's own contributing guide, and it is the fastest way in. Parts of this base predate the current shape of the projects; saying which parts, with the date, is work that makes everything above it more trustworthy.
The whole argument, in public.
Nothing about Drayker is decided somewhere you cannot read. Dknowledger is the public knowledge base of the whole system — papers, architecture and roadmap for every project, kept together so the reasoning can be followed instead of hunted for. What is published is a mix of current work, older material kept for the record, and gaps nobody has filled yet. Those are three different things, and the sites do not blend them: read the date before you trust the page.
Every term this site uses, defined where it stands.
The system has its own words, and using them without defining them is how a reader gets lost. Open any term: the definition says what it means and, where the specification is still missing, says that too.
{{ g.d }}
Published under a Creative Commons Attribution 4.0 International License; every site is open source. Dates matter more than titles here — check when a document was last touched before treating it as current.
Public infrastructure is not a product. It still costs money.
Drayker is a volunteer, non-profit effort to make large-scale coordination work: a protocol for distributed collaboration, and the architecture of the system that protocol is being used to design. Research and documentation continue on volunteer time. Implementation at scale does not.
Supporting it early is not buying a product. It is deciding that a public, reviewable, unowned method for building infrastructure should exist — and paying for the part volunteers cannot carry.
Written, argued, not yet built.
Seventeen public repositories hold the protocol, the kernel architecture and the organizational design. What exists is documentation, models and an open contribution process. What does not exist yet is a running kernel, a running network, an operating federation or a funded team.
Research and documentation remain active, and voluntary contributions are open. Large-scale implementation depends on sufficient funding. Participation does not imply compensation, and the concepts described here are not claims of an operating global system, financial product or medical service.
Four things money changes here.
Money is one of six.
Pick the one that describes what you are offering — it becomes the title of the public proposal you open at the end of this page.
What support does not buy.
These are not negotiating positions. They are the reason the work is worth supporting in the first place.
What happens next, in order.
The first conversation happens in public.
Nothing on this page is transmitted anywhere. It composes a public GitHub issue, opens it in a new tab, and you decide whether to publish it — under your own account, after editing whatever you want.
Because it is public: keep confidential figures, contracts and personal data out of the first message. Anything sensitive belongs in the conversation that follows, not in the opening issue.
{{ jLt }}
{{ jLb }}
{{ resTrackTitle }}.
{{ resTrackDesc }}
Each one names, on its own page, exactly what is missing from it. That is where a first contribution lands easiest.
Nothing is open in this track at this exact moment — which is itself an opening. Take one of the gaps above and open the issue yourself; a well-modelled issue is how every function on the board started.
Five layers, seventeen repositories. What you picked is lit; everything else stays visible, because nothing here is closed to you — you can cross layers whenever you want.
Introduce yourself in the open.
Optional — everything above is already yours to take, and nobody has to approve you. But an introduction is how people in your track find you, and it is the fastest way to get a first function cut with someone.
This page sends nothing and asks for no email. It writes a public GitHub issue from your answers, opens it in a new tab, and leaves publishing entirely to you.