Trust begins with scope

Give the work a boundary before you give it momentum.

A Palari starts inside one defined domain: what it may read, what it may prepare, and where a person must decide. Managers see structured records and review state, not private working notes.

Visible agreement

Scope, sources, policies, and review live together.

Human judgment

Prepared drafts wait until the owner approves.

Sofia · Grants

Grant renewal draft

Waiting approval

Sources used

2025 funder guidelinesLast submitted renewalBoard-approved impact metrics

Policies checked

  • Only grant-domain files
  • Budget numbers need owner review
  • No external submission access

Review surface

Renewal narrative prepared from approved context; budget changes are held for owner review.

Draft only. Nothing sent.
Structured recordPrivate notes withheldPerson approves next step

Scope and permissions

Trust starts as a visible working agreement.

Sofia helps with funding work because Maya gave her a narrow domain, named sources, and a plain permission boundary. Expanding scope is a review decision, not a hidden setting.

Approved sources are named before work starts.
Writes, sends, and memory changes wait.
Managers see review state without private notes.
S

Sofia's scope

Grants Palari

Owner: Maya. Domain: funding work.

Draft only

Can read

  • Grant folder
  • Prior reports
  • Shared language notes

Can prepare

  • Summaries
  • Drafts
  • Review notes

Needs permission

  • Edit files
  • Save memory
  • Send updates
  • HR, Finance, student, or patient records

Held until Maya approves

  • Editing the renewal doc
  • Saving a funder preference
  • Sending the update
  • Connecting outside tools

Manage the work, not the worker.

Maya sees scope, sources, drafts, decisions, and approval state through Task Cards and Completion Cards. Private conversations with a Palari stay outside the management record.

Tool recommendation is not tool connection.

Sofia may suggest a tool or setup path, but account connections and vendor data sharing stay outside the pilot unless Maya approves that scope.

Sofia prepares the draft. Palari does not send, delete, share, or expand access from this working agreement.

Management clarity

Manage the work, not the worker.

Managers can review scope, sources, drafts, decisions, and approval state. The work lives in Task Cards and Completion Cards, not in private conversations with a Palari.

People keep their own working space. Teams still get coordination, standards, and management clarity.

Standard templates

Recurring work follows the same shape each time: request, context, draft, open questions, and next step.

Source trails and review state

Every prepared answer can show what shaped it and whether it is draft, ready for review, or approved.

Manager visibility

Managers see the work record, blockers, and review status. Private working notes stay private.

The scope argument

A narrower surface is easier to trust.

Defined scope makes review possible. You decide where each Palari is allowed to look, what it can prepare, and which permission moments must stay human.

Broad reach

Harder to review

More reach can mean more review work.

Many AI tools are pitched around broad reach: many documents, inboxes, and systems at once. That can be useful, but it also makes the review surface harder to explain.

Many source typesShared ownershipWider permissions
The team has to reconstruct which source, rule, or permission shaped the answer.

Reviewable scope

Reviewable

A Palari starts inside one approved domain.

Sofia drafts grants. Marco runs permits. Rashida reads rulemakings. Each Palari has their own folder, their own tools, and their own permissions, so the review trail can get clearer before anything broader is added.

Approved sourcesNamed reviewerHeld actions
Task Cards, Completion Cards, and Team Policies show what is allowed before work moves.
Reviewable scope beats broad reach when people need to approve the work with confidence.

Progressive trust

Scope widens when the review trail earns it.

Start Sofia in one place. Expand only after the team has seen real work, source trails, and permission requests inside the scope she already has.

  1. Day 1

    Read-only start

    One folder, clear visibility

    Sofia can read /grants/clearwater/ and describe what she finds.

    No edits, sends, memory writes, or access changes.

  2. Week 2

    Reviewed expansion

    Drafts in the same folder

    After the team has reviewed real drafts, she can propose edits in /grants/clearwater/.

    A person still approves what lands.

  3. Month 1

    Wider read, same write

    More context, not more authority

    Read access can extend to /grants/ so Sofia understands adjacent context.

    Write scope stays where the team already reviewed her work.

  4. Month 3

    Review-first workspace

    Full grants workspace

    Sofia can draft across /grants/ once the trail shows she is useful there.

    Edits, sends, memory writes, and new access still wait for human review.

The Golden Rule

Permission stays visible at the moment work would move.

Writes, sends, memory changes, new sources, and outside tools are presented as review moments. The point is simple: the team can see what is being asked, who approves it, and what changes afterward.

Review moments

Held
WritesSendsMemory changesNew sourcesOutside tools

Continue exploring Palari

Trust gets stronger when memory stays reviewable.

Memory is the next trust layer: what Palari proposes to keep, where it applies, and how a team can review it before work repeats.

Next

See reviewable memory

Understand what Palari proposes to keep, where it applies, and how teams review it.

Continue

See Palari Domains

Start with one kind of work, scope, checks, and permissions.

Continue

Read privacy boundaries

Check data boundaries, exports, deletion, and beta limits.

Continue