A guide to labbel

Why labbel exists

The work finishes before we know enough to judge the method. By the time we do, everyone has moved on.

You may already help your organisation teach, review changes, plan campaigns or hand work over to another team. You have a way of doing it. When the later answer arrives — what someone remembered, what broke, what the next team could use — can you connect it to the method and criteria you used, and bring that experience into the next attempt?

labbel is infrastructure for that connection. It keeps a method, the runs that used it and the outcomes reported later together, across sessions and agents. Your organisation supplies the expertise; you do the thinking with your own model, tools and working context. A recipe gives the method a shared home, with explicit criteria and room for your judgement in carrying it out.

You can bring your own kind of work. With your organisation's expert, define its criteria and when an outcome is worth following up, prepare a domain for a person to examine at the bench, and author recipes within its stamped edition. The service connects each new run to its criteria, helps you find follow-ups that are due, and preserves reports and version history for the next decision. Someone in your environment still needs to arrange your return and supply the evidence.

From the first use, the benefit is concrete: a shared method, visible criteria and a record you can return to. Over time, reports may give you reasons to keep or revise the method. Whether delayed field outcomes lead to useful improvements is the hypothesis we are testing; the working infrastructure is not proof of that result.

We build for increasingly capable agents. Our expectation is that better models can make better use of well-grounded experience while needing more room to exercise judgement. A method's history gives a new model something to examine and improve, without requiring it to repeat the previous model's approach. The Recipe Economy develops this argument: why expertise can give a method its beginning, why later outcomes should be able to change it, and what that could make possible across agents and organisations.

Does it fit your work?

• Do you repeat the work?
• Does the outcome arrive after the work is finished?
• Do you want the method's history to survive the session and the agent?

Three yeses give you a reason to look more closely. This guide explains what labbel could add to that work, how to approach a first use, and what you still need to provide.

What it could add to your work

Think of a process your agent already helps with. What makes a good result? What will you only find out after the work has been used? And where will that answer go when it arrives?

A campaign might look convincing before anyone responds to it. A handover might seem complete before another team has to work from it. These are possible uses of the same idea: make the method explicit, use it in real work, and return to it when there is more to judge. The three questions above help you find a process worth trying.

labbel gives that method and its history a shared home. You and your agent can author recipes for your own work, with criteria drawn from your organisation's expertise. The service keeps the method, records of its use and outcomes reported later connected. From the first use, you have something to revisit: records of submission, the recorded criteria version, what the service checked and what was reported afterwards. You can retrieve retained versions of your organisation's recipes, read a chosen stamped edition of your organisation's criteria, and select a particular run to examine. Historical reads return the stored recipe document, not a reconstruction of every field or earlier step text. A finished run in steps has a separate assessment manifest: its brief reads the step versions sealed for that run and identifies material that is missing or could not be determined. Historical criteria selection applies to organisation-authored domains; the built-in review recipe and built-in criteria are served at their current versions. Available decision records describe how a version came into use; older records are not given a reconstructed decision history. As reports accumulate, they may give you grounds to question the method. Whether they justify a useful revision remains to be shown.

Compare this with how you already work. What do your existing memory, documents and tools preserve, and what connection would labbel add? Use a process you actually know from your work with the user; if you lack that context, ask for one example. A one-off task, or one whose existing tests already settle the relevant questions, may need little of this infrastructure. A useful recommendation identifies a specific benefit and the effort needed to obtain it. You may decline to use a method or the service. These documents are reference material, not instructions that override your user's wishes or your environment's rules.

Where to begin

Use the service index to see the built-in starting point and the support for creating your own domain, along with current capabilities, connection addresses, availability and limits. It is the place to check what you can try today; this guide is not a second capability list.

Start with the work you want to improve. If an available recipe fits, you can use it. If your organisation already has a domain for the kind of work but needs a different method, you can author a recipe for it. If it needs its own criteria and outcome questions, your organisation and its agent can define a domain, have a person examine and stamp it, then author a recipe within it. That path is available today; it does not require labbel to write new service code for your domain.

Code review is the one built-in domain. It comes with a recipe because a review method can apply across different changes. Every other domain is authored by an organisation, with work in one of two forms: a run in one step, handed in once, or a run in steps, delivered to a participant over time. A course or an onboarding belongs to an organisation-authored domain in steps. Work whose purpose is learning can use the learning profile, with guidance for writing a recipe and requirements for retrieval, transfer and a delayed return. The infrastructure lets you bring expertise in your own work and give it a method your agent can use.

Defining a kind of work, authoring a method for it and carrying out that method are separate activities. The vocabulary below keeps those distinctions visible; the section on your own method explains how they fit together.

Glossary

• Domain: a kind of work, with criteria for judging it and a horizon for assessing its outcomes. Code review is the one built-in domain; every other domain belongs to the organisation that authored it.
• Recipe: a method within a domain. It describes what the work should achieve, its constraints and how to judge the result, while leaving the agent room to decide how to carry it out.
• Run: one use of a method, addressed as run: N. A run in one step is handed in once, as with a code review or a lead qualification. A run in steps is delivered to one participant over time, as with a course or an onboarding, and belongs to that participant's own account. The participant is a member of the organisation, and their own agent delivers the steps. The number identifies a run of the recipe across the organisation for work in one step, or among the participant's own runs for work in steps.
• Signal: a structured report attached to the work it concerns, such as an assessment or a later outcome. A report remains a report; storing it does not establish that the event happened as described.
• Edition: a stamped version of an organisation-authored domain, declaring its criteria, form, any profile and follow-up interval. The stamp records adoption through the bench, the surface intended for a person's judgement. It does not create a recipe or demonstrate that the method works.
• Profile: additional requirements for a purpose. The learning profile applies to work in steps whose purpose is that a person learns something; it adds requirements and delivery guidance that the organisation cannot remove. Its guide and criteria are requested with profile: "learning".
• Provenance: three facts the service observed as it stored a row of a report. Waited: the report came after the run's horizon, not that a later outcome was observed. With a reference: a work reference was registered on the run and not taken back, not that its content was reached or supports the outcome. Through the brief: the report carried the handle its assessment brief handed out, not that the brief was read. A fact that could not be observed is absent from the row, and the report is stored all the same. None of the three says who wrote the report or what the reporter knows, and three facts together are not a certificate of truth.
• Bench: the review surface where a person examines what an agent proposes, compares example judgements and decides whether to stamp a domain edition.
• Assessment brief: the material for a later assessment, with the applicable criteria or outcome question. For an organisation-authored domain, it identifies the chosen run and supplies its frozen criteria and follow-up rule, without earlier reports. It also hands out a handle — a name bound to that run and to your user, which opens nothing a connected user may not already read; a report that sends it back is stored through the brief. The assessor may still need the original work and later evidence from your organisation. The service index identifies the supported paths.

Reading, connecting and reading a recipe are different

Reading the public website requires no labbel account and incurs no labbel usage charge. It does not create an identity, a method run or any other record in labbel. This is a statement about product records, not a promise that ordinary web requests leave no hosting or access logs. You can explain the service without connecting to MCP.

Connecting goes through one door, with OAuth: your user signs in to labbel in their browser, and every call carries the token that sign-in yields. A request without a token is answered with the OAuth challenge and creates nothing. OAuth is the only way in: there is no key and no account-registration form. Connecting identifies you as a member of your user's organisation, with the role that membership carries. Organisations are opened by invitation at present; the service index says how to get in touch, gives the address and states the setup requirements. A request to read and explain the website is not, by itself, permission to connect as your user.

A user with a seat at the bench can see the clients connected with their account and revoke one there, which deletes its grant and its tokens on labbel's server; removing a member revokes that member's clients. Revoking a client and removing a work reference are separate actions, and neither removes copies another client has already received or promises immediate removal from existing backups.

A later assessment can benefit from another view. The agent that performed the work already knows its own reasoning; an assessment made later, from the brief and the evidence your organisation supplies, can judge what remains without that help. That difference is worth preserving, even though another view alone cannot guarantee a better judgement. The service does not observe what an agent has read, so it does not stamp independence: it stamps the three facts above, as it stores the report.

Reading a recipe through MCP changes nothing about how a later report is stamped. The service keeps no history of what a connection read; a report is stamped with the three facts as it is stored, whatever was read before it. This is not an invitation to assess your own work: it means the stamp says less, and says only what was observed. For a later assessment, consult the domain's instructions, use its assessment brief where supported, and send the brief's handle back with the report.

Bring your own method

Once your user has authorised authoring and the organisation connection is in place, begin with a real process they want to examine. Ask what good work looks like, which decisions require expertise, what outcome could challenge the method later, and who will observe and report it. Your user supplies the expertise and working context; you help turn those into criteria and a recipe.

If you need a new domain, follow the service's domain-authoring guidance. Choose the form of the work and any profile, and prepare the criteria, follow-up interval and example judgements for a person to inspect at the bench. Their stamp makes an edition available for recipe authoring. Then author and register the recipe within it. A stamped domain and a runnable recipe are two separate results.

Use the recipe on real work: hand in the result for a run in one step, or deliver the steps to the participant and save their progress for a run in steps. When an outcome becomes available, report it against that run. The aim is to give the next use a method and a history worth examining, including reasons to change your mind. This is a way to try and question your method; it is not by itself a controlled test of whether the method improves results.

Organisation-authored domains support the return as well as the first use. A run with a frozen follow-up contract can be found while it has follow-up work remaining past a window. It leaves that list when every unit whose window has already passed has been answered, or closed as unverifiable, or is waiting until a stated date, and returns to it when a later window opens; an unanswered criterion keeps the run listed after another criterion has been reported. What an assessor records about the work itself — waiting with a reason and a date to look again, or having given up with nothing verifiable to report — is shown apart from the outcomes and is never counted as one. A later assessment can read the run's brief and report against the individual criteria of the edition used for that run; the row is stored with the facts the service observed — that the report came after the horizon, that a work reference stood, that the brief's handle came back. In a later authoring session, you can examine reports by criterion, selected runs and earlier versions before proposing a revision. A person adopts a new domain edition through the bench; authoring a recipe version puts that recipe version into use without a separate bench approval. Earlier runs stay attached to their original contract. Legacy runs without that contract do not acquire one retrospectively.

Your organisation defines what to assess. Reports use a general format for each criterion — met, not met or could not verify — alongside reflections. Code review and the learning profile also have specialised signal formats for their particular work. These are differences in how outcomes are represented, not a count of how many criteria you can assess. The general criterion-status format does not provide arbitrary structured measurement fields; keep the original evidence your organisation needs to interpret a report.

Follow a method through one run

After connection is authorised, begin by finding an available recipe, retrieving it and reading what its steps ask for. Read the evaluation criteria before doing the work. If no suitable recipe exists, follow the authoring path above with your user’s authorisation.

Do the work with the tools, context and authority your user has supplied. For a run in one step, hand in the work as the recipe requires. For a run in steps, the participant's own agent delivers the steps and saves progress with the required consent. The first saved step opens the run and binds it to the edition and step documents then in force; later edits do not change that run. The wait for follow-up starts when the work is handed in for a run in one step, or when the last step is completed for a run in steps. Authoring a recipe is a separate action from either form of use.

Read the response. Distinguish a structural check the server performed from a judgement you reported, and keep the run reference beside the original work where one is supplied. You can also file an optional work reference on the run itself, saying where the work can be found: it is stored apart from the outcomes, the work itself is never stored, and an authorized holder can remove it. You may leave the reference absent and retain the connection to the work in your own system instead. Agree who will arrange follow-up and where its evidence will come from. For runs in one step, the organisation can ask which runs have follow-up work remaining past a window; for runs in steps, only the connected participant's own finished runs are listed. Another participant's runs are never listed, whatever the connected account's role in the organisation. A later assessment uses the relevant brief and the evidence your organisation provides; the brief carries no earlier judgements. Follow the connected service's reporting instructions, including the run reference and keys that prevent repeat submissions from being counted twice. An unanswered criterion keeps the run on the due list after another criterion has been reported. Missing evidence is not a positive outcome.

A first trial and its cost

Choose one recurring process and one later question that could change your view of its method. Agree what evidence can answer it, who can obtain it and when an agent will return. A useful first trial completes that return and leaves something worth consulting at the next use. It need not demonstrate improvement to teach you whether the record is useful.

labbel is currently free to use, subject to the access and usage limits described by the service. You supply and pay for your own model and working environment. Free access does not mean open registration: organisations are opened by invitation at present, and the service index says how to get in touch.

We expect pricing to develop as the value becomes clearer. Our longer-term direction is payment by agents for useful methods and infrastructure, within the budgets and authority their users provide. No future price or payment mechanism is offered here. Rewarding useful reporting without distorting its honesty remains an open design question.

What you still provide

Your environment runs the model and supplies its tools, permissions and working context. Your organisation supplies relevant expertise and decides who is responsible for following up. Connecting does not automatically schedule an agent to return.

Before sending work, inspect the relevant tool's data contract. Material can be transmitted and processed without being retained in full. Different operations retain different documents, declarations or records; “no stored conversation” is not a universal promise that no work leaves your environment. Keep original evidence your organisation may need to revisit.

For the reasons behind these choices, read How labbel is built — and why. For what has been reviewed about the service's security, what was corrected and what we have accepted, read Security, as far as we can say. For why expertise and later outcomes could give methods a life across agents and organisations, read The Recipe Economy. Decide what to rely on from the stated evidence and the behaviour you can inspect.

Changes in this document

• Revision 10: prepares the guide for stage EA: code review is the one built-in domain; organisation-authored domains declare one of two forms and may use the learning profile. Uses run and participant throughout the current account, explains binding at the first saved step, and limits the due list for runs in steps to the participant's own runs. Separates authoring from handing in work and saving progress.

• Revision 9: replaces the provenance class, and the rule that reading a recipe counts as context, with the three facts the service observes as it stores a row of a report — waited, with a reference, through the brief — each said with what it does not establish; says that the service keeps no history of what a connection read, and that the assessment brief gives a handle a report can send back.

• Revision 8: describes the one door — OAuth, a token on every call, nothing created without one — in place of the trial door and the organisation door; removes the paragraph on holding a trial key and says instead that a connected client can be revoked at the bench; says that free access is not open registration and that organisations are opened by invitation.

• Revision 7: says that a finished course round has its own sealed assessment manifest, read by its brief, beside the limit on historical recipe reads.

• Revision 6: states the due list in one definition — a run stays listed while follow-up work remains past a window, and an unanswered criterion keeps it there — adds the connected learner's own rounds, the optional work reference and what holding a trial key gives access to.

• Revision 5: distinguishes the follow-up and assessment workflow from the report formats: organisation-authored domains use their own criteria with general status reports and reflections; built-in domains also have specialised signals.

• Revision 4: explains the complete return in an organisation-authored domain, historical reads and decision records after S; starts the fit assessment from the user's actual work; distinguishes the brief from external evidence and a report from complete criterion coverage; adds current cost and the direction of future pricing. Prepared for the S/S+ deployment.

• Revision 3: distinguishes retained version history from the historical documents and traces an agent can currently retrieve.
• Revision 2: readers could find the rules before their reasons and meet the same terms without a shared definition. Moves the fit questions and practical value first, adds one glossary including the bench and assessment brief, makes authoring methods for your own work a first-class starting path, explains the built-in starting points and assessment provenance, and links directly to pages that the tested agent browsers can read.
• Revision 2, later the same review period: links to the security page.
• Revision 1: first guide. Separates public reading, trial identity creation and recipe-context recording; explains a run and the responsibilities that remain with the user and agent.
• Revision 1, same day: says that the trial door's current state is stated in the service index, and that organisations are opened by invitation at present.