{{ heroTitle }}
{{ heroBody }}
Intelligence is scaling faster than any way of sharing what it makes.
Most of what a person could contribute is never used. Not for lack of talent and not for lack of will — for lack of conditions. Hierarchies filter what gets through. Work goes undocumented and has to be done again. Decisions cannot be traced back to a reason. Problems arrive larger than any single team can hold.
Machine intelligence is now becoming the productive force of the century, and it is arriving into exactly those conditions. It can take over most of the work people currently do in order to survive. Inside the arrangements we already have, that concentrates the result and leaves the people it displaces with nothing to do. Inside an arrangement designed for it, it hands back the part that was always worth having: creating, discovering, learning.
The answer is not slower intelligence. It is an arrangement built for it, and an arrangement is made of specific things: work cut small enough that anyone can take a piece and finish it; decisions recorded where anyone can audit them; resources reaching the work that was actually delivered, under incentives written down where they can be argued with.
Intelligence in that arrangement is not a tool bolted onto an organization and not an authority placed above one. It is symbiotic: a person and an agent hold the same system on the same terms, learning moves between them, and what gets amplified is the capacity people already have and cannot currently reach.
That is what Drayker is designing, in public. This site is careful about the distance between what is written and what runs — and about the difference between what is unwritten and what is simply not published yet.
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.
The method covers the first three links and is the part in use today. The organization and its economy are how the last four are meant to come back to the people who did the work — and they are the parts still being written.
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-five 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. Every person is carrying something they have never had the conditions to use.
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 that a person can spend their life on what they are actually for, and so that civilization can build, scale and act at a level it never could before.
Work here is meant to stop being a way to survive and become a way to take part. Study and work converge; the repetitive load goes to the machines; what stays with people is the creating, the discovering and the learning — the part no one should want to automate away.
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.
Which is also why resources are part of the design and not an afterthought. A system that produces value and cannot say where it should go rebuilds the hierarchy it replaced. Here the intention is that what someone delivers is what gives them standing, and that the rule doing the distributing is public enough to be argued with.
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.
The rest of this site is written the way documentation should be. This part is not, and it is kept that way on purpose: somewhere on a page about people, a person should be audible.
Almost everyone I have met was carrying something they never got to use. Not a talent in the romantic sense — a question they wanted to follow, a thing they would have been good at, a problem they could see clearly and had no way to work on.
Conditions decided that. Conditions are made of arrangements, and arrangements can be rebuilt. That is the whole of the motivation here: not to make people useful to a system, but to build a system where what a person is already carrying finally has somewhere to go.
We are not trying to replace anyone with intelligence. We are trying to reach the part of ourselves that has never had the room — and if the machines take the work nobody wanted, that is the point, not the loss.
Drayker should end up larger than anyone who started it, and it should be possible to argue with everything written here. That argument is not an obstacle to the work. It is the work.
What this is not.
A problem, cut small enough for the world to solve.
Distributed Functional Modeling is the collaboration paradigm behind every Drayker project: model the problem first, then modularize it into functions. It adapts to different domains, but the logic is always the same — model, fragment, distribute, review.
It is also the reason the rest of Drayker is possible. If people are going to keep the creating and the discovering while machines carry everything else, the work has to be cut so that a person and an agent can claim the same function on the same terms — and so that finishing one never requires holding the whole system in your head.
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.
A proposal is argued with, not approved: what it has to survive is people who read it properly.
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.
This page is about who decides. What a delivery is worth, how it turns into standing, and how standing is meant to reach resources — including what the value layer explicitly is not — is on the economy page.
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.
Reviewing, translating and writing a page count the same as code here. What the work is for is on the manifesto; what it earns you is on the economy page, stated plainly, including what it does not.
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 whose public description is still to be written. 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 has no public document — the first one 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-five 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.
What you delivered is what gives you standing.
In one sentence: work that is finished in public earns reputation, reputation is meant to become weight in decisions, and weight is meant to open access to resources — with no salary, no token to buy and no return to anyone.
This page exists because this is the part of Drayker that gets misread most often. The first link of that chain runs today. The rest is design, and this page marks which is which line by line.
Four links, and only the first one runs.
The order matters more than any mechanism: standing follows delivery, and everything downstream follows standing. Change that order and the arrangement becomes the one it was meant to replace.
{{ e.d }}
The mechanism is reputation, not a currency.
Reputation here means one specific thing: the public record of what somebody delivered and what they reviewed. It is not a score for being liked, being early or being present. It is not transferable, because the thing it describes is not transferable either.
It already exists in a rough form. Every merged contribution is attributable in the history of the repository it landed in, and anybody can read it without asking permission. What does not exist is the counting: how a delivery becomes a number, how that number gives weight, and what stops the number from turning into a private form of power.
A token would be a primitive version of the reputation points — not a second thing standing beside them.
A unit of value can express part of what reputation expresses, and it expresses it more crudely: a number that can change hands forgets who earned it and why. That is exactly the property the design is trying to avoid, which is why the material describes value that carries its own rules rather than value that is simply spendable.
Today none of it exists. Nothing is issued, nothing is priced, nothing is for sale, and holding anything would entitle you to nothing. In the internal Drayker material this unit is called Dktron; on this site it is a design question with open answers.
Five things this is not, and will not quietly become.
What runs today, and what is only designed.
Drayker is in its founding phase: research and documentation are active, participation is open, and implementation at scale depends on funding that does not exist yet. Nothing in the designed column is a commitment — it is what the material describes and what the specifications would have to establish.
The funds and the value unit are described in Drayker material that has not been published yet. Publishing it, and reconciling it with what the repositories declare, is itself open work.
Four answers this layer needs before it can exist.
These are the questions the design has not settled. Anyone who has worked on governance, accounting, cooperatives or mechanism design is better placed to answer them than we are — and answering one in public is a contribution in the exact sense the method means.
The whole argument, in public.
Nothing about Drayker is decided somewhere you cannot read. Dknowledge 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.
Twenty-five 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, twenty-five 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.