Phaeacia Agent Passport
00The document

Passport · spec 0.1 · checked 2026-09-28

Install this agent pick your assistant, copy one block

In the gallery under Writing and editing, listed 2026-09-28. See the rest of it

Phaeacia Type A · read-notify
Page 1 of 4

Agent
Passport

Bearer

Proposal First-Draft Builder

proposal-first-draft-builder
Purpose

It turns a client's brief, RFP or call notes into a structured first draft of a proposal, reusing only the approved boilerplate, methodology, team bios and comparable case studies you point it at.

the first line of the owner’s description

The bearer

Page 2 of 4
No portrait
Software bearer
Name
proposal-first-draft-builder
Title
Proposal First-Draft Builder
Issued
2026-09-28
Link expires
Listed in the gallery, does not expire
Capture path
file
Envelope
read-notify
Source stack
Python pipeline behind a local web app on macOS; local open-weight models via MLX, a large tier for drafting and a mid-sized tier for the two analysis steps; local folders plus optional Notion pages, read-only
Scrub
regex+llm, owner-reviewed
Signed by owner
Confirmed this description

Source stack is where this agent ran before it was captured. Your rebuild does not need it, and nothing in the install tries to reproduce it.

Observations

It turns a client's brief, RFP or call notes into a structured first draft of a proposal, reusing only the approved boilerplate, methodology, team bios and comparable case studies you point it at. It runs when you ask it to, one brief at a time. The draft is for an expert to revise before anything reaches the client: every section says whether it is reused material, new reasoning or a placeholder, pricing stays blank unless you supply a figure, and anything the brief leaves open or contradicts lands in Open questions instead of being invented.

The machine-readable zone

Page 3 of 4
PAPHAPROPOSAL<FIRST<DRAFT<BUILDER<<PROPOSAL<PROPOSALF3PHA2609289F2609289V01C04I04L00Y<10

The real passport format, with real check digits, computed from this file.

Read it field by field
L1 1-2PADocument type. P for passport, A for the read-notify envelope.
L1 3-5PHAIssuing authority. This site checked the format and stored the file.
L1 6-44PROPOSAL<FIRST<DRAFT<BUILDER<<PROPOSAL<The name field: the identifier, then the title, split by a double filler.
L2 1-10PROPOSALF3The identifier, and its check digit.
L2 11-13PHAIssuing authority again, where a passport carries the bearer’s nationality. An agent has none.
L2 14-202609289Issued 2026-09-28, and its check digit.
L2 21FCapture path: file.
L2 22-282609289Checked 2026-09-28, and its check digit.
L2 29-43V01C04I04L00Y<1Spec version, 4 capabilities, 4 installable, 0 losses declared, owner confirmed.
L2 440Composite check digit over positions 1-10, 14-20 and 22-43. Positions 11-13, 21 and 44 are excluded, as ICAO 9303 excludes them.

Two lines of 44, in the ICAO 9303 TD3 field positions, with check digits computed on the 7-3-1 weighting. Every value is read off this passport. An agent has no nationality and no date of birth, so those positions carry the capture path and the date this file was checked instead, and the legend above says which is which.

Entry permissions

Page 4 of 4

What you will need

2required

  • Read the client brief you paste or upload (text, Markdown, Word or PDF)
  • Show you the finished draft

2optional

  • Read your approved proposal material from folders you name
  • Read approved material kept in a knowledge base behind your login, read-only

Each one is an account or a permission on your own platform, and you grant it yourself when your assistant asks. This passport carries no credentials, and nothing is granted by reading this page. Declared only means the original agent had it and version 0.1 will not install it.

Read the client brief you paste or upload (text, Markdown, Word or PDF)

The brief is the only source of facts about the client; every client claim in the draft is cited to it

Requirement: Required

If you skip it: No draft: the run returns a two-line notice asking for the brief

Installable in v0.1: yes

GrantedRequired

Read your approved proposal material from folders you name

Boilerplate, methodology, team bios and case studies are what the draft may reuse, quote and cite as proof

Requirement: Optional

If you skip it: The draft is still written, from the brief alone, and you are warned up front that it will be thin: Team becomes a placeholder, Relevant proof points says no case study is comparable, and nothing is marked as reused material

Installable in v0.1: yes

GrantedOptional

Read approved material kept in a knowledge base behind your login, read-only

The same material, for whoever keeps it there rather than in folders

Requirement: Optional

If you skip it: Only folder material is used; if neither is connected, as above

Installable in v0.1: yes

GrantedOptional

Show you the finished draft

The draft is the whole point of the run

Requirement: Required

If you skip it: Nothing reaches you

Installable in v0.1: yes

GrantedRequired
In the owner’s words

The last column answers whether the format allows installing each row, not whether your platform can do it; the installer checks that against your platform before asking you to agree.

Granted means version 0.1 will install that capability. Not granted means it is named here, and left out, so you can see what the original could do that your copy will not.

Checked 2026-09-28 against rules 0.1.0 presented 43 times before this

01Evidence

One golden example, copied from the passport.

Golden examples are what the passport offers as evidence that the agent does what it says. Your rebuild is checked against these. This site checked the file's format, not the truth of its examples.

One example, the newest of three saved runs; the other two came from the same brief and settings and have the same shape. Nothing was elided. It is a template of shape, never expected content: the installer runs this on their own brief, with their own material, and a different draft is the correct result.

> Values this run instantiated, rather than fixed parts of the shape: the client name and the brief (a 96-word set of call notes, so the sparse-brief instruction applied) were supplied with the request; no budget was supplied, so the Pricing text is the fixed placeholder; no approved material was connected, so Team is a placeholder and Relevant proof points has no case study; the section list, voice and the three checklist lines are the slot defaults. The line opening Open questions ("Contradiction in the brief, please resolve: ...") was inserted by the contradiction gate, not written by the drafting model. The client in this brief is invented test input.

Captured 2026-09-27:

## Proposal outline - **Executive summary**: High-level overview of the engagement, acknowledging the tight timeline and budget constraints. [New draft] - **Understanding of need**: Restatement of the client’s current state (paper/Excel), objectives (mapping, recommendations, online shop), and constraints (no new licence budget, German workshops, November board decision). [New draft] - **Proposed approach**: Outline of the six-week methodology, focusing on process mapping and low-cost implementation strategies for the online shop. [New draft] - **Workplan**: Six-week timeline aligned with the November board decision and winter launch. [New draft] - **Deliverables**: List of outputs including process maps, recommendations, and the live online shop. [New draft] - **Team**: Placeholder for team composition, as no bios were provided. [Placeholder] - **Pricing**: Placeholder, as no budget or pricing was supplied. [Placeholder] - **Assumptions**: Key assumptions regarding the definition of "simpler setup" and the technical approach to the ticket shop without paid licences. [New draft] - **Relevant proof points**: None of the approved case studies is comparable to this brief. [New draft] - **Open questions**: Critical gaps regarding scope, technology, and timeline. [New draft] - **Reviewer checklist**: Required internal reviews. [New draft] - **What the user should do next**: Immediate next steps for the consultancy team. [New draft] ## Executive summary [New draft] Verein Bergbahnen Obertoggenburg operates three small ski lifts and a summer hiking shuttle, relying on volunteers for ticketing and scheduling via paper and Excel [S1]. We propose a six-week project to map these current processes, recommend a simpler setup for the 2027/28 season, and implement an online ticket shop for the coming winter [S1]. This proposal addresses the constraint of having no budget for new software licences this year while ensuring the board has a decision-ready plan by November [S1]. ## Understanding of need [New draft] The client seeks to modernize its ticketing and volunteer scheduling operations, which are currently managed manually [S1]. The primary objectives are to map existing workflows, recommend a simplified operational model for the 2027/28 season, and launch an online ticket shop before the upcoming winter season [S1]. Key constraints include a strict six-week project duration, workshops conducted in German, a board decision deadline in November, and a zero-budget constraint for new software licences this year [S1]. ## Proposed approach [New draft] We propose a six-week engagement divided into three phases: discovery, design, and implementation. During the discovery phase, we will conduct workshops in German to map current ticketing and volunteer scheduling processes [S1]. In the design phase, we will develop recommendations for a simpler setup, focusing on solutions that do not require new paid licences [S1]. The implementation phase will focus on deploying an online ticket shop using available or free-tier tools to meet the winter launch deadline [S1]. ## Workplan [New draft] - **Weeks 1–2**: Process mapping workshops with volunteers and staff in German [S1]. - **Week 3**: Analysis of current processes and identification of inefficiencies [S1]. - **Week 4**: Development of recommendations for a simpler setup and selection of online ticket shop solution [S1]. - **Week 5**: Implementation of the online ticket shop and integration with existing tools [S1]. - **Week 6**: Final review, board presentation preparation, and handover [S1]. ## Deliverables [New draft] - Current state process maps for ticketing and volunteer scheduling. - Recommendations for a simpler operational setup for the 2027/28 season. - A fully functional online ticket shop live for the coming winter. - A board presentation summarizing findings and recommendations for the November decision. ## Team [Placeholder] [Team lead: to be confirmed] [Consultant: to be confirmed] ## Pricing [Placeholder] [Pricing placeholder: no budget or pricing was supplied for this draft. Add pricing after commercial review; do not send this section as it stands.] ## Assumptions - Inference: The "simpler setup" for 2027/28 will prioritize low-cost or free software solutions to align with the no-new-licence budget constraint. - Inference: The "coming winter" refers to the winter season starting in late 2026, requiring the online shop to be live before then. - Inference: The six-week project timeline is flexible enough to allow for the November board decision while still meeting the winter launch deadline. - Inference: Existing Excel and paper-based systems will be integrated or replaced by the online shop without requiring significant new hardware. ## Relevant proof points None of the approved case studies is comparable to this brief. ## Open questions - Contradiction in the brief, please resolve: Budget vs. Deliverable. "They mentioned they cannot pay for new software licences this year" versus "They want an online ticket shop live for the coming winter". The draft above has not resolved this. - How will the online ticket shop function without paid software licences? Will free tiers, open-source solutions, or existing tools be used? - What is the specific definition of "simpler setup"? Does it include hardware, specific software features, or just process changes? - What is the current technology stack? (e.g., Excel versions, paper formats) - How many volunteers are involved, and what is the current ticket sales volume? - What are the specific dates for the "coming winter" and the "six-week project"? - How does the board plan to evaluate the proposal? Are there specific criteria beyond the stated objectives? ## Reviewer checklist - [ ] Commercial review of pricing, payment terms and scope - [ ] Legal review of any commitment, liability or IP wording - [ ] Delivery lead review of the workplan and staffing ## What the user should do next 1. Confirm the specific definition of "simpler setup" and the technical approach for the online ticket shop given the budget constraint. 2. Provide details on the current technology stack and volunteer numbers to assess complexity. 3. Confirm the specific dates for the six-week project and the winter launch deadline.
02Install

Pick where you are installing, then paste the block into that assistant.

You get one branch, not all four. The other options stay available if you picked wrong.

Building the block for this platform.