Obligation Layer

This is the current map of what I am working on and thinking through.

I build trust infrastructure for messy coordination problems: AI-agent operations, service workflows, local pilots, and public proof systems where people need to know who promised what, what money means, what evidence exists, and what can safely be said in public.

The category is explicit boundary systems. The mechanism is an obligation layer. The artifact is a boundary packet.

That sounds abstract, but the practical point is simple:

People have obligations. Other people have capacity. Money changes what is owed. Trust fails when the story, money, obligation, governance, and proof are implicit.

The work is to make those boundaries explicit enough that useful coordination can happen without pretending everything belongs in one company, one charity, one co-op, one fund, or one platform.

This is infrastructure, but not a public database over private life. It is a protocol for naming what kind of commitment exists before people move money, time, space, labor, or trust.

The Short Versions

If I only have a few seconds:

I build proof systems for bounded trust loops: clear money labels, explicit obligations, protected private context, and public evidence people can inspect.

If I have a minute:

A client buying consulting, a funder supporting a public artifact, a household joining a grocery demand signal, a tenant looking for a sublet bridge, and a local business offering spare capacity all create different obligations. The mistake is to blur those into one platform story. The work is to label the money, define what is owed, keep sensitive context private, and publish only the proof that has been reviewed.

If I have a real conversation:

I am trying to make useful coordination less dependent on vague trust. In consulting and Sitelayer, that means scoped work, delivered artifacts, and callback proof. In Winnipeg, it means small local pilots around grocery demand, housing gaps, workspace capacity, and civic-economic maps. In Sandolab and taylorsando.com, it means public demos, essays, diagrams, and proof cards that let people inspect what happened instead of taking a pitch on faith. The point is not to make one giant platform. The point is to keep each stream honest about what money means, what was promised, what evidence exists, and what boundary prevents abuse.

The Operating Principle

Story decides money. Money decides obligation. Obligation decides governance. Governance decides proof. Proof decides what can be public.

That is the simplest way I have found to keep different kinds of work from contaminating each other. A client payment, a patron contribution, a rent bridge, a cooperative due, a grant, and a regulated investment are not the same kind of money. They create different promises, controls, records, and public claims.

If the money label is wrong, everything downstream is wrong.

The Ecosystem

The shared layer is a boundary packet:

• stream;
• story;
• money label;
• obligation;
• governance rule;
• trust boundary;
• evidence;
• review state;
• proof card.

People should tap into reviewed projections and scoped packets, not the raw graph.

The lanes stay separate on purpose:

• taylorsando.com is the human and consulting entry point.
• Sandolab is the public proof lab.
• Sitelayer is the commercial product loop: capture, concern, dispatch, callback, closeout.
• Winnipeg is the local testbed for civic-economic coordination.
• Plane is the private operator cockpit, not the public story.

Why This Exists

The failure mode I keep seeing is not only lack of effort or lack of money. It is mislabeled coordination.

Someone thinks they are donating. Someone else thinks they are investing. Someone thinks they are doing a favor. Someone else thinks they are hiring. Someone thinks a room is temporary spare capacity. Someone else thinks it is a tenancy structure. Someone thinks a project is public proof. Someone else thinks it is confidential operations.

The obligation layer is meant to force the label before the commitment.

The Streams

For-profit services

Clients pay for concrete outcomes: reviews, audits, implementation, Sitelayer work, agent/control-plane architecture, and advisory.

The proof is ordinary and direct: scoped work, invoices, delivered artifacts, review notes, and public case studies only where permission exists.

Sitelayer and Cavy

Sitelayer is the commercial product loop. It is not a social experiment and does not need the whole philosophy attached to it.

The useful part for Sitelayer is narrower: requests, field context, estimates, callbacks, evidence, closeout, and permissioned proof. If a Sitelayer case study ever becomes public, it should be sanitized and approved by the people involved.

The immediate point is to get the formal product loop moving and make the proof machinery survive contact with a real business.

Public proof and writing

Sandolab and taylorsando.com are the public layer: essays, proof pages, diagrams, public build records, and examples of how the systems think.

The return here is understanding and trust, not a financial claim.

Plane and the operator console

plane.sandolab.xyz is the private operator cockpit. It is where the unstable working state should get tracked day to day: current stream, clock label, goal, task, capture, decision, and proof packet.

The public site should explain the frame. Plane should keep the private execution ledger from dissolving into loose notes.

Local trust pilots

Winnipeg is the place to test local coordination: food costs, local businesses, demand aggregation, civic-economic maps, and concrete project rooms.

Food Fare-style grocery demand aggregation is the cleanest first example: households signal a staple-basket need, a local retailer gets better demand visibility, and proof is published only after costs, savings, labor, spoilage, and store constraints are measured.

Housing and rental gaps

Housing is a high-value capacity lane, not a standalone rental marketplace.

Some people need a room, sublet, assignment bridge, deposit bridge, arrears bridge, or short-term sparse living arrangement. Some people have spare room capacity, lease gaps, vacancy risk, or temporary space.

The target version would be narrow: screened, low-support working adults, explicit rules, private housing-gap packets, aggregate public proof. It is not crisis housing, treatment, sheltering, or a speculative landlord product.

This is not the first pilot. Anything tenancy-adjacent needs legal review before it becomes operational.

Commercial and work-space capacity

Commercial space is another capacity lane, but probably not the first acute bottleneck in Winnipeg because affordable coworking and incubator space already exists.

The useful forms are more specific: project rooms, pop-up retail tests, workshop/event rooms, maker/prototyping access, storage, after-hours underused rooms, and sponsored space for public-good work.

Mutual aid and obligation splitting

Some problems are monthly cashflow holes. A specific obligation may be too large for one person at one time but small if divided across a trusted network.

This has to stay explicit: no guarantees, no investment return, no vague community fund, no implied insurance. The proof is the named obligation, the money in, the decision, the privacy boundary, and the outcome.

The narrower working note is the Trusted Obligation Bridge: a private-network pattern for direct bill support, repayment timing, housing capacity, sublets, substitution support, and proof cards without pretending the loop is a financial product.

Cooperative and member systems

Some loops may eventually need member ownership: households, workers, local businesses, supporters, or capacity providers funding shared infrastructure that reduces costs or improves access.

The important lesson from the old community/co-op notes is that open source is not enough. Technology needs governance, ownership, accountability, labor rules, dispute rules, and a charter.

Fenced investment and insurance

Anything that promises financial return, enforceable coverage, risk pooling, upside, revenue share, profit share, debt, or equity belongs behind legal and accounting gates.

Do not blur it into mutual aid, patronage, housing support, or co-op language. A disclaimer is not a gate.

First Proof Cards

The first proof cards should be low-risk and already close to reality.

Each public proof card should answer the same six questions:

1. What need, request, or capacity was named?
2. What money label applied, if any?
3. What obligation did that create?
4. What evidence exists?
5. What stays private?
6. What changed, failed, or needs the next decision?

The private cards live in the operator console. Public cards should be projections: reviewed summaries that hide raw names, addresses, private funding terms, legal context, relationship notes, and anything that would turn a useful trust loop into a public dossier.

Example: a software delivery proof card might say that a team had an agent-review bottleneck, the engagement produced a risk map and implementation sequence, operational details stayed private, and the public claim is limited to the pattern and artifact type.

Example: a local grocery proof card might say that a bounded group tested whether a staple-basket demand signal helped a local store reduce friction or cost. Individual households stay private. Public proof covers the demand signal, pickup process, measured savings or non-savings, friction, and repeat/stop decision.

The public index starts here: Proof Cards.

Software delivery proof

A paid or advisory engagement gets a scoped packet: what was requested, what money meant, what was delivered, what evidence exists, what remains private, and what public claim can be made.

This validates the basic loop without inventing a new legal category.

Sitelayer callback proof

A real workflow gets traced from request to field context, work item, evidence, callback, and closeout.

This proves the product loop without turning Cavy/Sitelayer into public theater.

Local obligation split

A small shared cost, capacity trade, or in-kind support loop among trusted people gets labeled up front and reviewed afterward.

This tests the thesis in the cheapest possible form: the ambiguous version would have caused confusion, the labeled version should not.

The public-safe version of this idea now has its own page: Trusted Obligation Bridge.

Not first: tenancy, investment, insurance, pooled risk, revenue share, or anything that requires a legal structure before the proof has a safe container.

How People Can Tap In

People do not need to join a vague platform. They can enter through a scoped role:

• client: bring a system, workflow, or product problem;
• patron or contributor: support a named proof packet, public artifact, or pilot;
• local operator: coordinate one bounded loop;
• capacity provider: offer a room, vehicle, store relationship, workspace, skill, or verified lead;
• person with a need: submit a bounded need with consent and privacy protection;
• verifier or voucher: attest to a narrow fact;
• funder: fund a specific public-good artifact, pilot, or coordination cost;
• developer or researcher: help make the evidence, tooling, and proof surfaces stronger.

Each role needs a boundary: what can be offered, what can be received, what stays private, and what can become public proof.

Where I Fit

For a team or business, I fit best as the person who can sit between the existing system, the operators using it, and the proof needed to make the next move. That may be an architecture review, an agent-readiness review, a build sprint, or a callback loop around a real workflow. The clean consulting entry point is still working with me.

For a local organization, business, funder, or group, I fit best around one bounded pilot: one need, one capacity source, one money label, one review point, and one public-safe proof card. If the pilot works, the evidence can decide whether it becomes a repeat process, a cooperative structure, a paid service, a public brief, or nothing.

For someone with capacity, the useful question is not "do you want to join a platform?" It is "what spare room, workspace, relationship, skill, equipment, buying power, or verified lead could become useful if the terms and boundaries were explicit?"

For someone with a need, the useful question is not "tell the internet your situation." It is "can this be stated as a bounded request with consent, privacy protection, and a clear decision about what proof can be shared?"

For a patron or funder, the clean lane is to support a named public artifact or pilot without claiming financial upside or control. If the story is financial return, insurance, debt, equity, revenue share, or profit share, it belongs behind legal and accounting gates before anyone treats it as an offer.

Start A Conversation

For consulting: send the workflow, system, or decision surface that is becoming hard to trust. The best starting point is usually a short review: what exists, where the boundary is brittle, what proof is missing, and what the smallest useful implementation sequence looks like.

For local or community conversations: bring one bounded problem, one real constraint, and one possible operator or partner. The goal is not to launch a platform. The goal is to decide whether one proof-carrying loop is worth testing.

Book a control-plane review, or email consulting@taylorsando.com.

What This Is Not

This is not a generic marketplace, a charity brand, a social-credit system, a reputation graph, an investment pitch, or a dashboard over private life.

No proof card should expose private hardship, private operations, or private relationship graphs just to make the system look more credible.

It is also not a reason to delay the work with actual commercial pressure. Sitelayer has to ship. Consulting has to deliver. Public proof has to stay honest. The obligation layer exists to keep those streams coherent, not to become a substitute for them.

It is a way to keep several live threads explicit:

• Sitelayer as the immediate product loop;
• Sandolab as the public proof layer;
• taylorsando.com as the concise personal/consulting entry point;
• plane.sandolab.xyz as the private operator cockpit;
• Winnipeg as the local coordination testbed;
• ProjectKit/capture as the technical contract for turning concerns into work;
• housing, food, and space as concrete capacity gaps;
• legal/financial risk fenced until it is actually structured.

The Practical Next Page

The next public shape is the proof-card index: a small set of named boundary packets showing what was attempted, what money meant, what proof exists, what remains private, and what changed.

For now, this page is the map.