Human–AI Systems Exemplars schema registry

Move a real question through a finite collaboration.

These loops connect public skills, authored source, observable evidence, and human decisions. Start with the job in front of you, stop at the named result, and check the current source and work state when the work resumes.

Collaboration loops

A collaboration loop is a finite route from a meaningful question to an owned result. Each example names where it begins, which sources govern it, what remains a human decision, what evidence fits, and the event that ends or reopens the work.

Loop 1 · recurring collaboration need

Let real use shape a skill

Sources: Practitioner Probe · Collaboration Accounting · Declarative Skill Authoring

  1. Turn the concern into a question whose answer can change a decision.
  2. Use the smallest suitable method in a real task.
  3. Record only the observation that changed routing, interpretation, authority, or the return.
  4. Retain, revise, rest, fold, or author a distinct skill when the evidence supports that move.
Entry
A recurring collaboration need has produced an observation that could change a decision.
Source owners
The current Practitioner Probe, Collaboration Accounting, and Declarative Skill Authoring source files.
Human decision
Whether a candidate becomes part of the team's working practice.
Evidence
The resulting work, changed decision, and focused observation.
Exit
A clear disposition and one named owner for any continued work.
Recovery
Return to direct reasoning or the earlier owner when a new contract adds more coordination than value.
Re-entry
A materially different use, human correction, or artifact behavior changes the route.

Loop 2 · visible experience

Change a visitor surface with fitting evidence

Sources: Context Canvas Surface Reading · CSS Ownership · Visual Verification

  1. Read the page as a visitor and trace every source responsible for its behavior or appearance.
  2. Name the intended visitor behavior and the smallest source-owned change.
  3. Implement through the page, component, style, or build owner.
  4. Observe the affected behavior at the viewports or interaction states that can answer the question.
Entry
A named visitor behavior needs a change in a known page or route family.
Source owners
The target page and the CSS, JavaScript, assets, or build source that determine its behavior.
Human decision
Audience, identity, publication, and any consequential interpretation.
Evidence
A focused source or browser check with its viewport and coverage boundary.
Exit
The accepted surface and its changed behavior are both easy to locate.
Recovery
Keep the earlier source or generated package available while a visible regression is repaired.
Re-entry
A visitor observation, source change, or new route reveals a material mismatch.

Loop 3 · resumed repository work

Re-enter, make one bounded change, and return it clearly

Sources: Repository Re-entry · Issue Chain Stewardship · Source Authority Mapping

  1. Confirm branch, revision, worktree, current Issue or pull request, and the nearest orientation.
  2. Resolve the current source and responsible owner, then name any difference from an earlier record.
  3. Complete one authorized change, then run the smallest check that shows whether the intended behavior works.
  4. Return the changed surface, evidence, remaining boundary, and exact next move.
Entry
A repository task resumes with a named question, issue, or requested change.
Source owners
The current branch and runnable source, with the nearest README, planning records, and GitHub state supplying orientation.
Human decision
Any scope expansion, external coordination, destructive action, or consequential acceptance.
Evidence
Current Git and Issue state plus the command or review that exercises the change.
Exit
The named receiver accepts the result—for example, a person approves the pull request, an Issue owner accepts the evidence, or a deployment operator accepts the package—and the return says where the work stops.
Recovery
Recheck the current source and work state when a branch, source, or receiver has moved.
Re-entry
The named receiver requests revision or the next issue in the chain becomes ready.

Loop 4 · accepted source to live delivery

Publish a repeatable, byte-comparable artifact through a named destination

Sources: Source Authority Mapping · Secret Boundary Inspection · Issue Chain Stewardship

  1. Bind the build to an accepted source revision and a named file set.
  2. Build so the same accepted inputs produce the same files, then compare file membership and bytes with the reviewed destination.
  3. Inspect the exact artifact for credentials or other secret material and keep the result scoped to those bytes.
  4. Let the named operator activate delivery, then observe public paths, media types, response behavior, and recovery.
Entry
An accepted source revision and its intended public destination are named.
Source owners
The accepted authored source, its build owner, and the declaration that names the public file set.
Human decision
Publication timing, destination, credentials, and host activation.
Evidence
Source and destination revisions, a file-set digest, a scoped secret-material observation, and public behavior observed without a signed-in session.
Exit
The accepted paths and bytes are live, or the package rests at its reviewed receiver.
Recovery
Keep the previous accepted package available and return to the first mismatched layer.
Re-entry
A new accepted source revision or live mismatch calls for another bounded publication cycle.

Pause without losing the return path

A Coordination Horizon is a short pause record that separates what is current, what can happen next, and what belongs later. The responsible source keeps state; the horizon keeps timing and return legible.

Example: a publication package can rest after source and byte agreement while host activation remains with a person. Resumption begins by comparing those accepted identifiers with the current source and work state.

Current
Accepted source, repeatable package, and comparison result are named.
Next
The authorized operator activates the receiving host and returns a bounded observation.
Later
Performance tuning or another delivery model begins only when live use creates that need.
Resume when
The operator returns evidence, the accepted source changes, or a public path differs from its receiver contract.
Release when
The named receiver accepts the result and no current decision remains.

Ask a schema useful questions

A schema can help anyone ask sharper questions before they write code or accept a system claim. Begin with the Context Canvas orientation, its exact schema, and the visitor-surface example. Then bring a real decision rather than asking the field names to tell a complete story.

Four questions that travel well

  1. What should this surface help someone decide or do, and what visible signal would show that it helped?
  2. Which parts describe observed behavior, and which remain illustrative, planned, or current with caveats?
  3. Who decides what the surface means and what happens next, and what may automation do before that decision?
  4. What evidence would change the present reading, and what is the smallest useful return move?
Source claimWhat the selected field or authored page actually says.
Mechanism and evidenceThe behavior or artifact someone can observe.
Counter-signalThe evidence that would change the present interpretation.
Transfer boundaryWhat the source leaves open in this setting.
Instruction yieldThe next useful action the evidence supports.
Stop or returnThe condition that ends the route or sends it back to an owner.

A request you can adapt

Read the linked orientation, schema, and example for the decision I describe. Form a small set of ordinary-language questions. For each question, name the source claim, the observable mechanism, useful evidence, a counter-signal, the transfer boundary, and the next action or stopping point. Separate behavior the source implements from options a team could consider. My decision is: [describe the real decision here].

This request supports planning and review; it grants no deployment, publication, access, or organizational authority. A person supplies the real decision and receives any consequential choice.

Common questions

Each short answer leads with the usable distinction. The public sources remain available when the current work needs more depth.

Which file carries meaning, and which file carries exchange or delivery?

The linked Markdown or authored page explains the method and its boundaries. JSON packages selected fields for software. A rendered page supports discovery and reading. The source named by the contract remains the place to resolve meaning.

Read the Collaboration Skills orientation.

When is a repository skill useful?

Use a skill when a recurring job benefits from a stable trigger, boundary, result, and stopping point. Direct reasoning is the smaller route when the current question is clear and added coordination would not change the decision.

Browse the public skills.

How does a collaboration loop finish?

A useful loop names its completion event before work begins. It may end with an accepted change, a bounded finding, a human decision, a deliberate pause, or a return to an earlier source when new evidence changes the route.

See the pause and resume example.

What does a validation result establish?

A result supports the behavior and revision exercised by that observation. Its coverage boundary says what remains open, such as visitor comprehension, live delivery, organizational fit, or a consequential human decision.

Read Stateful Artifact Behavior Contracts.

How can these materials support planning or practitioner conversations?

Start with a real decision. Use a schema or example to surface intended outcomes, source ownership, authority, observable evidence, counter-signals, and a return path. Those questions can structure a planning review, implementation discussion, role design session, or practitioner conversation.

Start with the schema-guided inquiry.

May these skills and examples be adapted?

Yes. The repository uses Apache 2.0. Preserve applicable notices, name the source and the adaptation, and keep the receiving system's decisions and evidence distinct from the upstream example.

Read the complete license. This page summarizes working practice rather than legal advice.

How can two AI collaborators review an integration boundary?

Give both collaborators the same public source package and receiving question. Compare faithfulness to source, compatibility, authority, evidence, counter-signals, and stopping conditions. A person retains decisions that carry publication, access, identity, or other consequential authority.

Read Source Authority Mapping.

Do I need a framework or orchestration script to use these loops?

Use the public source directly with a platform that fits the work. A framework or script can help when repeatability, coordination, or integration earns the added structure. The platform and environment determine how long a collaborator can work and which actions it can complete independently, so treat those as observations for each use.

Begin with the simplest route that can produce the named result. Add orchestration when the receiving work demonstrates a material need for it.