Cycle explorer

Why: A rule that stops something on your laptop gives you no explanation, and an inbox for it would be one more thing to check.

Result: One record, the finding, is shared by your laptop and the company: it goes up whole, follow-ups come down onto it, and what was stopped in time stays the gentlest case.

Next: The Peterson conversation from peterson.md; then qnative's cycle from qnative-brief.md, whose step 0 is design's (each policy's configuration in the sidecar). Committed in 81f3ee59ee, unpushed; c149 builds the simulation's prevented rows against it. · waiting on Mark Peterson

Why: qcontrol's settings file had no page, and people will ask their agents to change it.

Result: A Config page with three sources and one check, and an agent that drafts the whole file for the person to apply. In the eval, 9 of 12 plain instructions got a correct first draft, and three one-line wording fixes brought the rest; the stand-in check still drifts from qcontrol's own.

Next: Phase 6: Guide 05 rewritten from a proposal into a contract, c145's configure step pointed at this page, the Outcome. Then F1 (link qconfig as the app's check) as a qnative cycle of its own, and the managed-machine instruction once C9 is answered. · waiting on Mark Peterson on C9; Tyler on Q6; engineering on the check, the write and the reload

Why: People learn security by seeing an incident, nobody can afford a real one, and an unlabelled pretend one is a hazard of its own.

Result: Six disaster stories that play in the lab's real dashboard, beat by beat on the person's Next, between one click on and one click off, with the findings worked out by the dashboard's own rules and pointed at one by one. Replaying them with one policy at Enforce shows what would have stopped each, and corrected the first draft in eight places. A show mode plays them unattended; the first story also plays in the native app.

Why: The desktop app will update often, and the part that installs updates had no screen, no choice and no notes.

Result: One Settings screen that says where an update stands, three ways to let it happen, a quiet trace after it does, and the same screen ready for a bigger rollout later. Eleven choices wait for Mark.

Next: Mark rules the eleven calls in review-1 (the preference's default, what invisible means, inline notes, skip, who owns the notes, one update or two, when an automatic install restarts, the version string, Settings' seat, the clock and the age line, the era as data). Then Phase 4: the rulings applied to the mocks, and the states pushed into qnative as stories through /gpui-story. · waiting on Mark's rulings; Tyler on signing, the updater, the feed's fields, qcontrol's update, package-manager detection and restart mechanics (T1–T6)

Why: The two tools our engineers use to watch the sensor are losing their home, and customers who measure every megabyte must not pay for them.

Result: A plan and nine rulings, then the first four phases built: the locks, the stream underneath, a page that picks fake or real data, and the live list itself, held to the web version by shared tests. The guide for hooking up a real sensor now asks for each thing once.

Next: Mark walks review stop 3's thirteen calls (qnative c3 review-3.md) and takes the 4-a-second readings of Live Activity; then Phase 4, Events, which needs his brief and mock first, and Phase 5, the Monitor, on the reconciled shapes. Still to be said: who gives the gate its expert review. · waiting on Mark's design for Events; Kamal's answers (the Guide's questions, page 4 for the Monitor feed); a Rust expert's review of the gate

Why: We knew the native kit is light; we did not know whether it can look and read like our web pages.

Result: Our building blocks rebuilt natively and scored, and the Inventory pages running on one laptop's data, close to the web pages beside them.

Why: When a rule blocks something on your laptop you get no explanation, and the fix could flood you with alerts from every direction.

Result: Every message from head office now has one shape and three sentences, and you decide which kinds reach you and how; the first release carries only the connection receipt.

Why: Partners will run Qpoint on their own servers, and when we need to get in to fix something, there has to be a safer way than sharing a password or a screen.

Result: A partner opens a time-limited door for a stated reason, picks how much we may touch, sees everything we do, and the door closes on its own.

Next: Phase 0, prior art, can run now; Phase 1, the model as data, once the plane's identity model is ruled. · waiting on c134 D2 (the plane's identity model) and Tyler's say on where grants live

Why: Our shared parts box grew fast while we built, and nobody has checked it for doubles, missing labels or thin instructions.

Result: Every part gets a scorecard against five checks, doubles are merged or retired, and the parts the dashboard built for itself move into the box, so the next app starts with a full one.

Next: Phase 0 on Mark's word: the scorecard script and the annotation standard; then the census and its review stop.

Why: The company dashboard is stuck inside the program on each laptop, and its sign-in cannot be run by a customer on their own servers.

Result: The dashboard becomes its own web app, shipped as one package we can run or a company can run itself; both apps are mapped and the backend's 30 gaps are listed.

Next: Phase 1, the shell mock (sign-in, org, the qdash home with the global filter); Phase 2, the contract written for Kamal after the call. · waiting on Tyler's repo decision and Kamal's availability

Why: When a laptop blocks something risky, the person sees a block and no explanation.

Result: A finding becomes a short lesson, sent as a message to the small app and recorded as proof. The shape is drawn, the model is data, and the first lesson, about an unapproved MCP server on one real finding, can be taken end to end in the lab. The trainings are now files the design site publishes, and all three pilots (unapproved MCP servers, personal accounts, secrets in prompts) run end to end from real findings. The hand-off to the web app and the native app is written, and a library lets a person take any of them on their own; the brief is still in flight.

Next: The next topic trainings from the guide's list (D50, D53): Finding and Severity, Sanctioned, Exception and Scope, Endpoint and Harness, then the operator terms, each through the /training skill's topic section; c134 and c131 take handoff.md (the training page, the record, the library, topics and the operator's send); Tyler to validate D22–D27 with training.completed.self and D55; Peterson on personnel data and the self-report. · waiting on Tyler on D22–D27 and D55; c134's person frame, the plane repo, the copy at release and the operator's send; Peterson

Why: The way we sketch and review screens today depends on web pages, and the new desktop app is not a web page.

Result: The five-step loop stays. The bake-off put a web look-alike of three screens beside the real desktop app on the same sample data: the look-alike took an agent twelve minutes, the real screens an hour on a day of groundwork, and the two agree row for row. Mark picks which one is the medium.

Next: qnative c5 lands D21 in B (Status as the landing, Sensor, Activity) and the bake-off page wipes A over the new B; c131 D17's routes replace the bridge; a world per state retires the knob and the story parameter; Events, Config and Connect next through the same loop. · waiting on qnative c5 for B; c131 D17 for the routes

Why: The small program that watches a computer's AI traffic could not carry the web dashboard without getting heavy.

Result: A small desktop app will show what was found on this machine; a first test version runs on a Mac with very little memory, and the second phase shows it can look and read like our web pages.

Next: Phase 2 is complete (qnative c2 closed 2026-11-11). The V1 build starts from c130's shape.md and c0's name; the violation tour comes with qnative c4 (c137 Phase 3), the Status page with c132 Phase 4, D17's routes with engineering (c134). · waiting on c130 shape.md and c0's name

Why: The dashboard lived inside the sensor and made it heavier than the sensor's promise; the team decided to split them.

Result: A program with a researched primer, a measured spike, and seven cycles each with a plan, so the native app and the control plane can be built in parallel without losing the thread.

Next: Phase 2, the shape (shape.md), fed by the primer and the spike; then the pitch for Tyler's requirements session and c0's naming walk. · waiting on the date of Tyler's session

Why: Two new things need names, and a name decides what customers think they are.

Result: A brief with the candidates placed by the model each attaches to, the agent's proposal, and a one-hour agenda for deciding as a team.

Next: The team's first pass on the names, then the shared session; then the rename and the records updated in one change. · waiting on the session date

Data without the controls: one window, three reports, and every number honest about the time it covers.

Why: The Reports page was a placeholder. C-level people, auditors and IT need what the dashboard shows without access to the controls, and the pages disagree about what time they cover.

Result: In progress. One shared time window, a Reports catalog and a fully drawn Posture report are live in the lab. Deployment status and Inventory have their outlines. None of it is in qdash yet.

Next: Work through the open calls in c123's intents-pr5-review.md, then port to qdash. · waiting on Mark's review of the four reports

A map that already works gets tuned by hand until one real story reads at a glance.

Why: The map's data pipeline works, but what it draws doesn't yet read clearly: what belongs inside what, what matters most, and what things are called.

Result: Not finished yet: one example story now reads as nested floors, with tools still being compared four ways. Nothing is committed except design's handoff note.

Next: Pick a tool treatment, add flows for the other five scenarios, and swap the grey balls for pawns as they get drawn.

Cycle pages now tell a story, credit outside helpers first, and an explorer shows every cycle at once.

Why: A cycle's page showed its full record. You couldn't see at a glance why it happened, what changed or who helped, and the people outside Qpoint who shaped the work went uncredited.

Result: Every cycle now opens on a short story with pictures and credits, people outside Qpoint first. A new explorer shows them all, and open ones say what they're waiting on.

Next: Mark reviews the explorer and the stories, then rules on the review list: which cycles close and which outside credits stand. · waiting on Mark's review

Evidence, not compliance: the frameworks get one page and one verb, and a close reading of OWASP becomes a tour of what Qpoint can actually do.

Why: This week is about compliance frameworks, and our CISO advisor Mark Peterson is leading what they should mean in Qpoint.

Result: In progress. Framework detail is composed in the lab, with one Track verb on the listing and the detail, and five product tours are live, one of them built from a close reading of OWASP's agentic paper. Policies' frameworks strip, the listing's percentage and tracking that stages policies are still to do.

Next: Finish the frameworks cleanup page by page: Policies' frameworks strip (X1, X2), Compliance's percentage (X5), tracking that stages policies at Observe (F8), SOC 2's mappings. Take after captures. Check Peterson's revised intents against intents-redline.md §5 when they land. · waiting on Mark's read of the pages; Peterson's revised intents

Taming our own history: a box of unlabeled drawings, from the first Q sketch in 2023 to last week, made findable without moving a file.

Why: Years of sketches, boards and decks sat in a shared drive with no dates or links, so finding anything old was a struggle.

Result: All 1,137 files in the design drive can now be found, previewed and opened from one page, including 3,627 Illustrator artboards. Tying them to cycles is not done yet.

Next: Start Phase 3: tag each library file with its cycle, startup phase and design generation, reviewing with Mark one folder at a time.

A week of advisor conversations reshaped the governance model, and every lab screen was rebuilt to match.

Why: Our security advisor showed us how real security teams think about rules, and our screens still showed the old ideas.

Result: Now every rule has one simple switch, you see who a change affects before you make it, and all changes go live together. Seven screens changed.

Next: Close it once Mark confirms frameworks belong to c123, moving the carried-forward items there. · waiting on c123

Six drafts to one sentence: the method kept its shape and changed the problem it points at.

Why: Qpoint now works on AI governance, but our design method still used data governance as its main example.

Result: The method now names AI governance as its hard problem, and the /method page opens with a sentence Mark wrote himself after six drafts.

A small, finished favor: the logo page stopped describing the logo and started handing it over.

Why: The logo page described our logo but had nothing to download, so anyone without Figma had to ask for a file.

Result: Now anyone can pick a logo, a format, a size and a color, and download a ready-made file: 195 files from five masters.

Next: Nothing left to build; write the Outcome and close it.

The day the policy model collapsed into one page: an advisor's Oct 19 session, proven in the lab overnight, half of it overturned two days later.

Why: An Oct 19 session with our security advisor changed how policies work, and we had one day to see if the new idea held together.

Result: The new model ran end to end in the lab within a day: one policy page holds the switch and every exception. Ten of eleven questions were answered Wednesday morning.

Before telling the story of AI as Prometheus's fire, we made sure every quote is real; the talk is still to come.

Why: We want to give a talk comparing AI to the myth of Prometheus bringing fire, and every quote in it has to be true.

Result: Not a talk yet: a checked library of sources on the myth, on learning from mistakes, and on what people now say about AI, plus a sources page on the design site.

Next: Run the two pending research tasks (Christopher Alexander and the people overviews), commit them with the held Roesler edits, then close it. · waiting on GitHub access for the two cloud tasks

A proposal overtaken in hours: we designed shopping carts with approvals, the advisor and team said one shared cart is enough, and the cart idea is what shipped.

Why: Every policy edit took effect the moment it was made. Mark wanted to edit freely across pages, then deploy, discard or send for approval as one unit.

Result: The full proposal was overtaken within hours. Its core idea, making a change separate from publishing it, became the one shared draft we built two cycles later.

An outside illustrator got one page per blog post, and the first one shipped from sketch to published hero.

Why: Sarah draws the pictures for our blog, but she can't open our code or private notes.

Result: Each blog post now gets a page Sarah can open, with the idea and the deadline. The first one became the picture on a published post.

Next: Write the Outcome and close it; new briefs are content now, not cycle work.

Our advisor's fourteen notes turned out to be one machine; we drew it on eight screens, then spent two weeks of sessions taking parts out until the simplest version was left.

Why: Our advisor wrote fourteen ideas for governing AI, and our screens described the same things in older, mismatched words across separate pages.

Result: The fourteen ideas became one model and eight connected screens to try it on. Two weeks of advisor sessions then made the model smaller, and later cycles built that.

Next: Update the pickup note and the object model with what the October product sessions decided, then keep building in the lab as c118, c121 and c123 need it.

From cooking to order to cooking ahead: the demo stopped computing answers live and started serving them baked, and every page went from timing out to under a second.

Why: The live demo was too slow on small servers: busy pages timed out and showed "Can't reach qdash".

Result: Every answer the demo can show is now worked out ahead of time and served as files, so any page loads in under a second. The daily refresh is built but not running yet.

Next: Add the storage token to the demo Worker, deploy the scheduled baker, run one bake by hand to time it, then close it. · waiting on Mark's R2 token

We built a fake company that never sleeps so the demo always looks alive; the world worked, the servers did not, and that failure is why c113 exists.

Why: Showing qdash meant running it on a laptop, and its made-up company was frozen in July, so the "active now" parts looked dead.

Result: We built a public demo whose fake company keeps working around the clock, in four sizes. It worked, but the servers were too slow, so the next cycle replaced how it is served.

The cycle numbers stopped telling time, so the work got a calendar: every week now has its own page.

Why: Cycles now overlap so much that their numbers no longer tell you what happened when.

Result: The cycles page gained a week-by-week view, and every week has its own page with what started, what closed, the code changes and the screenshots. The backfill and digest are still to come.

Next: Hand the records backfill and the digest rewire to c124 or the backlog, then write the Outcome and close it.

The Activity page stopped counting sessions and started answering who used how much, and what it cost.

Why: The Activity page counted sessions, but people ask about tokens and cost, and two of its cards weren't earning their place.

Result: Activity is now two rows of three: sessions, tokens and cost, then providers, models and harnesses. The cycle's write-up isn't finished.

Next: Nothing left to build; write the Outcome and close it.

After ten cycles of placeholder landing pages, the home page became a newspaper front page for the whole fleet.

Why: The Inventory and Organization landing pages had said "Design in progress" for about ten cycles, and the home page had nothing on it.

Result: Those two menu items now just open their lists, and the home page shows the whole fleet at a glance: 35 small summaries, each matching its own page.

The dashboard stopped saying "all clear" when it simply hadn't heard back.

Why: While loading or offline, the dashboard showed comforting all-clears like "Fleet is clean" or a perfect score of 100, before it knew anything.

Result: Every page now tells loading, failed and truly empty apart. A failed save says so and undoes itself. The false all-clears are gone.

Three dashboards became one: the app everyone already used became the app the product ships, and nothing was lost on the way.

Why: The product still shipped an old dashboard nobody worked on, while the app everyone worked on shipped nowhere.

Result: The app everyone used became the one the product ships. The old apps were archived, not deleted, and their best fixes came across first. Tyler's review is still to come.

Next: Nothing left to build; move the Outcome to the history and close it, leaving the pull request review parked.

A long page used to lose its own name when you scrolled; now the name rides along at the top, and nothing on the page jumps.

Why: When you scrolled a long page, its name scrolled away with it, so you could lose track of where you were.

Result: The page name now stays pinned at the top beside the filter, shrinking out of the way as you scroll. It shipped on every qdash page.

A cost page that listed everything and answered nothing gets redrawn around the three questions real buyers ask.

Why: The cost page was built before the app knew much about cost, and it answered none of the questions managers, finance and the CFO actually ask.

Result: Not finished yet: a redrawn Cost Center mock answers spend, pace and rate first, with one table that breaks spend down eight ways.

Next: Commit the cycle and its mock, get Mark's review of mock round 2, then port the cost page to the app. · waiting on Mark's review

A one-line bug fix exposed three sticky bars that didn't know about each other, and the answer was to make them one.

Why: Long tables never kept their header in view, and fixing that made the header slide under the section tabs.

Result: One sticky bar now holds the section tabs and the filter together, and table headers stick right under it on eleven pages.

One review day reorganized the whole menu and taught three pages to show which way their numbers are heading.

Why: Mark's next review reorganized the app's menu and asked, page after page, how to show the trend next to today's number.

Result: The menu now groups pages by job, Sessions became Activity, Teams shows a spend trend per team, and Users leads with who needs attention.

A page of review notes became thirteen careful page changes, each photographed before and after.

Why: Mark reviewed fourteen app pages and left a page of notes; each note needed to become a real change.

Result: Thirteen pages changed one at a time, each previewed and reviewed. Tiles say what they count, and Teams leads with coverage.

A renderer that never found a product home meets a question every detail page asks, and the cycle hands it to a designer instead of drawing it.

Why: Every detail page lists what a thing can reach, but lists hide the shape of the answer, and our 3D map tool had never found a real job.

Result: Not finished yet: nothing is in the product. A designer has the brief, six example sessions now tell the story of a broken rule in plain words, and qmap has started staging the first one.

Next: Keep staging the six stories in qmap c29, which so far has flows for the first one only. Then settle how tools are drawn, and which characters to draw next. Deploy when the sessions page should be readable off this laptop. · waiting on the designer's first round is still not on record, though the qmap work isn't waiting on it

Ten false starts at "the landing" became one deliberate bake-off, and its best drawings became full pages, then the small cards on Home.

Why: The app's big overview pages had split into four empty placeholders, and ten earlier attempts at "the landing" never reached a pick.

Result: Eight bake-offs and composed mocks for Home, Inventory and Team, plus new library pieces. Later, Inventory and Team folded into Home's small cards.

Next: Get Mark's picks on the Home and Fleet mocks; until he has time, park it with a pickup note. · waiting on Mark's picks

Every page checked, a rulebook written, and the whole app rebuilt on it twice, so the method could be judged, not just the result.

Why: Every page of the dashboard fetched its data its own way, and nobody had written down how pages, parts and data should fit together.

Result: A written rulebook for how pages get data, and every page rebuilt on it, twice, by two AI builds. One build became the product's app a few days later.

Next: Nothing left to build; write one closing Outcome that records the Fable app as the choice, and close it.

The sidebar learned to say where you are, and its look was dialed live on the demo.

Why: Inventory had grown nine listing pages, but the sidebar listed nothing under it, so you couldn't tell where you were or reach them easily.

Result: On any Inventory page, the sidebar now opens to show its nine listings with the current one lit. The Fleet section moved up to second.

A real inconsistency, a careful plan, and no work yet.

Why: The same AI tool, like Claude Code or Cursor, is drawn differently on almost every page: different logos, sizes and labels.

Result: Not built. A plan exists to survey every place a tool is drawn, settle ten questions with Mark, then make one shared chip. Nothing has started.

Next: Give it a new cycle number and decide whether one shared harness chip is still wanted; if not, close it.

The page histories gained their true first chapter: Devin's June prototype, dug out and brought back to life.

Why: The page histories began at our first design mock-ups, but the product really began earlier, as a quick prototype Devin built in June, with almost no pictures left.

Result: Fifteen page histories now open with that prototype: six screenshots recovered from old code history, and fifteen new ones from rebuilding it and feeding it replayed activity.

Screenshots learned which page they show, and a page's history became something you can scrub through.

Why: Screenshots of the same page piled up across cycles under different names, with nothing tying them together, so nobody could see how a page had changed.

Result: Every capture now names the page it shows. A new view lines up each page's history and compares any two moments by wipe, fade or side by side.

Two finished tools fought over one spot; joined, they became the one strip above every table.

Why: Every listing had two controls fighting for the same spot above its table: the quick filter and the new column picker.

Result: One strip now holds both: filter keys on the left, Columns on the right, across every listing. Three known gaps and the promised visual design are still open.

Next: Write the Outcome, move the three known gaps to the backlog, decide whether the Figma design is still owed, and close it.

Mark's meeting notes became a routine: one page, one plan, one preview, one review.

Why: Mark's page-by-page meeting notes became work by hand, and the hand-offs leaked: lost lines, misread fragments, and every helper briefed one by one.

Result: A todos skill now reads the notes straight from Logseq and writes one plan per page. Its first run made 17 plans, all carried out that day, one page at a time.

Next: Nothing left to build; write the Outcome, list the follow-ons, and close it.

A small Columns button gave wide tables room to breathe, and the next cycle carried it into every listing.

Why: Listing tables were getting wide, and nothing let a person hide the columns they didn't need.

Result: A Columns button now opens a checklist that shows or hides table columns, with a badge counting what's visible. The next cycle moved it into the library and onto the app's listings.

Next: Nothing left to build; write the Outcome pointing at c95 for the extraction, and close it.

The call tool stopped asking "who's interested?" first and started asking "what problem does the user have?"

Why: market-analyst was built to size up a market, but it now mostly feeds design, and briefs were written by hand because calls weren't sorted by the user's problem.

Result: Fifteen user problems now sit in a registry, each with the question it asks of the product. Calls tag them, the site leads with them, and design cycles cite them.

Next: Review the waiting candidate problems and the two advisor-driven standing changes, then decide on the product-input plan. · waiting on Mark's review of the product-input plan

Nine days took the mocks off the film set and into the product, one shared part at a time.

Why: The new page designs lived only as mocks on made-up data, while the real app still had hand-made filters and older pages.

Result: Over nine days the mocks became real pages on real data: one filter with an always-on time window, a chart on every listing card, one frame for every detail page. Phase three stayed open.

Next: Write the Outcome of what each thread landed, hand the open items to the current app's backlog or drop them, and close it.

Two stat cards from a mockup became one flexible part, and the idea behind it got a name.

Why: A new stat-card design needed one flexible part, and Mark saw the pattern our map tool had found: a rich base with a few ready-made presets.

Result: DataMachine shipped in the shared library with two copyable presets. The base-plus-presets idea is now written into our design method.

Separate mock rooms became one walk-through behind a front door, the last stop before the real app.

Why: Each page mock lived alone on the design site, and Team Details and a Devices list didn't exist, so nobody could click through the whole flow.

Result: Seven pages now sit behind an app-like sidebar and click through as one flow. Three were reworked against new annotated mockups. The record's Outcome was never written.

Next: Nothing left to build; write the Outcome pointing at c92 for the real-app port, and close it.

A ring where there's a whole, a plain number where there isn't: two listing mocks taught one honesty rule.

Why: The Teams page showed coverage as bare fractions, and there was no page listing sessions at all, only one session at a time.

Result: Teams now shows coverage as rings and names the people who need attention. A new Sessions page puts the sessions worth a look first. Both were early mocks, later copied forward.

Next: Nothing left to build; move its finished Outcome to the history and close it.

The filter left the one app it was stuck in and came back as a single bar the next cycles used everywhere.

Why: Our older web app had a working filter bar that no other project could reuse, and its redesign existed only as mockups.

Result: The old filter now lives in the shared library as a legacy set. A rebuilt bar and a new quick-filter strip follow the mockups, and both share one filter state.

Next: Nothing left to build; drop the step for the unused app, move the leftovers to the backlog, and close it.

A hand-drawn week of coloured squares became a chart that counts from seven days to sixty without growing too tall.

Why: We needed a chart of activity over days, like sessions per AI tool each day, that works for a week, a month or two months.

Result: A new shared chart draws each day as small stacked squares, one lane per series. It scales from a week to two months and is documented with many examples.

A name and a blank page: there is no story to tell.

Why: Unknown. The cycle was opened with a name and an empty prompt file, and nothing says what it was for.

Result: Nothing was done. No plan, no pages, no images. Any guess at its purpose would be made up.

Next: Ask Mark what Machine Status was meant to be; if nothing, close it as abandoned or delete the empty folder. · waiting on Mark's answer

Mark's labelled sketch of a chat became five shared parts, down to the little tail on each speech bubble.

Why: We needed to show what a person and an AI agent said to each other, and the earlier attempt was only sketch code on a demo page.

Result: Five shared components now show a chat session: speech bubbles, folding tool calls, and a small ruler for jumping between turns. They're documented and reusable.

Four ways to ask "what is design doing right now?", and a grid that answered it on paper but never reached the real page.

Why: The cycles page was a good archive, but it couldn't say at a glance what design was working on, what was stuck, and what needed a decision.

Result: Four directions, rough then real, and one promoted design: a grid of every cycle by stage and need. The real cycles page never adopted it.

Next: Write an Outcome saying the production slice was never built because later cycles took the page another way, then close it.

An advisor's enthusiasm isn't a customer's proof; now the tool can tell them apart.

Why: The tool read advisors' and teammates' enthusiasm as customer proof. In one call, 12 of 21 findings came from Qpoint's own people.

Result: Each call now declares who is talking and why, every finding says whose view it is, and code decides what counts as proof. By that rule, none of seven use cases is proven yet.

Next: Nothing left to build; write the Outcome and close it.

A worry written down in one paragraph, whose practical half was solved the same night by someone else.

Why: Our shared component library had just become public, which made cloud installs easier, and Mark had misgivings he wanted to explore.

Result: Not started. The cycle is one paragraph. The practical question, installing the library in the cloud, was answered the same night by c82's run.

Next: Ask Mark whether the worries about a public library need their own cycle; if not, close it as answered by c82. · waiting on Mark's answer

Parked in the morning, run the same night: the cloud built seventeen pages unattended and taught us to save after every step.

Why: Mark wanted to know whether a whole design cycle could run in the cloud while his laptop was closed.

Result: It could. One overnight run built all seventeen Phase 1 pages unattended. But the cycle has no formal record yet, and the index still calls it parked.

Next: Write a short record from the first-run notes, answer or retire its two open questions, and close it.

Seventeen pages drawn at once on one made-up company, then four of them drawn again after the advisor walked them.

Why: Phase 1 called for 17 dashboard pages about people, teams and their AI tools, and the product had only an early prototype.

Result: All 17 pages exist as mocks on one made-up company, each opening with a one-line verdict and a calm all-clear version. Four got a second pass after an advisor walkthrough.

Next: Nothing left to build; write the Outcome, capture the four second-round pages, and close it.

A two-word sticky note: there is no story to tell yet.

Why: Unknown beyond the title. The only note says a help overlay was "currently in design" somewhere else.

Result: Nothing was built or written here: no plan, no pages, no images.

Next: Ask Mark what the help overlay was; if nothing picked it up, close it as abandoned. · waiting on Mark's answer

An advisor's first call split one inventory page into two: the technology and the people.

Why: Our new security advisor said inventory comes first, but our one inventory page mixed agents, machines and people. The call settled on two views: the technology, and the people.

Result: Three polished mocks on the design site: technology by company, people with sensor coverage and spend, and one person's detail. The product's inventory and people pages grew from them.

Next: Commit the cycle folder, write the Outcome pointing to the product pages it led to, and close it here and on the design site's list.

Bring the pipeline up to date, and decide not to add a database.

Why: The pipeline still used patterns from early in the year: an old Claude library, no caching, one giant analysis prompt. Mark also asked whether it was time for a database.

Result: All six pieces landed in a day. Repeat calls reuse a cached prompt, analysis runs per use case and per company, and the answer on a database is no, for now.

A confusing error in chat apps traced to one missing final step, handed to engineering, and fixed.

Why: Chat apps running under our sensor kept failing with a decompression error, and nothing showed that our own proxy was the cause.

Result: We traced it to our proxy never finishing one kind of compressed stream, and wrote down the fix and a missing test. Kamal fixed it three weeks later.

Next: Nothing left to do; write the Outcome noting qcontrol's upstream fix, and close it.

An advisor's list of verbs and deadlines became the rules for a finding, and three days later the product's findings page ran on them.

Why: An advisor told us what security teams do with a finding and how fast they must fix it. Our reports assumed that workflow, but nothing in the product did it.

Result: Findings in the product now group under their rule, carry a status and a remediation clock, and can be ignored or accepted as risk with a reason. It shipped within three days.

Next: Nothing left to build; write the Outcome, hand its open threads to the governance cycles, and close it.

Four reports a CISO actually hands out, drawn in full, and a front page that is only their summary; the final card pick never came.

Why: Our advisor listed four reports a security team needs, and our founder framed the landing page as a summary of them. None of the four existed yet.

Result: All four reports were mocked in full on one shared shape, with a landing page of four summary cards. Mark never picked a card style, and on 2026-11-03 the work closed into c128 Reports, which carries on its report shape and the Board report's summary.

A session became something you can read, first as a layered record and then as a chat, and the chat idea outlived the cycle.

Why: The product records everything an AI session does, but there was nowhere to read it: a link promised a session's full story and went nowhere.

Result: Two mocks: one session read at four levels, from receipt to raw events, and a bake-off reading it as a chat. Not finished yet: the timeline, footprint map and final page were never built.

Next: Write the Outcome saying the chat idea went on to Session Details, mark the unbuilt mocks as dropped, and close it.

Make the project make sense to the next person who opens it.

Why: The team was about to open the project, but the guides were wrong in places, a copy of the skills had drifted, and adding a new call wasn't written down.

Result: In one day the docs were fixed, then rewritten for the pivot: setup, every command, how to read the data, and how to add a new conversation.

New company, new questions: freeze the old calls and read the new ones for evidence about AI agents.

Why: Qpoint turned from watching API traffic to governing AI agents. The call tool still asked the old company's questions.

Result: The old calls were archived as a browsable snapshot, the questions were rewritten around AI-agent use cases, and the dashboard now leads with the evidence for each. Two pilot calls ran clean.

Next: Write the Outcome and close it; what was left now lives in c10, c11 and c12.

A one-line wish that was never started; a later brief to Sarah takes up the job.

Why: The colors behind light and dark mode were harder to define than they needed to be, and the wish was to make them simpler.

Result: Not started: only a one-line note was ever written. The same job now sits in a dark-mode brief that asks Sarah to choose the dark colors by eye.

Next: Never started; close it as superseded by the dark-mode brief.

A hand-shaped card became a reusable piece on the design site, but never made it into the shared library.

Why: The cycle cards on the atlas listing were hand-written markup. Once Mark finished shaping them by hand, they were meant to become a reusable part.

Result: Half done. Mark's card became a local component the same morning and now serves three pages. It never moved into the shared library, and the archive's similar card was never switched.

Next: Decide whether the cycle card moves into the shared layer; if not, write a short record of the local extraction and close it.

A good question about how we build parts, asked and not yet answered.

Why: We had principles for shared components, but no rules for the moment of making one: a reusable pattern or a one-off special part, shared or local?

Result: Not started. The question and where to look for answers were written down; no rules, skill or worked examples were produced.

Next: Add a pickup note and list it in the cycle index so it reads as parked, with the qdash app as its model when it resumes.

Adding an integration became a guided setup that shows you the message before anything is sent.

Why: Adding an integration led to a disabled form that said "not wired". Operators had no way to set one up, and no help finding the keys and IDs.

Result: A guided setup window for all 11 integrations, each with real fields and step-by-step instructions, reused for editing. Notification channels also preview the exact message they'll send.

Next: Check that the current app kept the setup modal, write the Outcome, and close it.

Cycle notes from eight repositories became one browsable album, with the missing photos taken.

Why: Cycle records were scattered across eight repositories, and many earlier cycles had live pages but no pictures. Nobody could browse the whole history in one place.

Result: Every cycle in every repository, 151 at the time, got its own page with its write-up and pictures. About 420 screenshots were taken, many showing an experiment in eight or more states.

A 2007 thesis, the root of our method, became a book you can read on a Kindle.

Why: Mark's 2007 master's thesis is the root of Qpoint's design method, but it survived only as one PDF of wide two-page spreads, hard to read on a Kindle.

Result: The thesis now lives in the repo in three forms: the original PDF, a Kindle e-book with its pictures, and a single-page PDF that reads as designed, plus its full text.

A day of sweeping the workshop: cycles filed, tools rebuilt, and the method put where every session reads it.

Why: Our tools and habits had grown faster than we tidied them: dozens of stale "active" cycles, uncommitted work, outdated commands, and a design method agents never read.

Result: Order restored in a day: 22 cycles filed, the backlog committed, commands rebuilt as skills, the method loaded into every session, and a script that photographs every page.

Next: Rule the six flagged cycles from the completion audit, write the Outcome, and close it. · waiting on Mark's rulings on six flagged cycles

The landing page's first job was settled, drawn fifteen ways, then hand-drawn as three cards.

Why: The dashboard's first page overlapped with the inventory page, and nobody had settled what a person should see first when they log in.

Result: An order for the first page: a one-line verdict, what needs you, then doors to each area. Seven mocks, ending in Mark's three cards. Picks never came; later cycles shipped it.

Next: Write the Outcome saying the landing page shipped through later cycles, ending with c109, then close it.

The Teams page learned how to sort people into teams, then spent a day finding how much picture a summary can carry.

Why: The Teams page repeated the cost table, made team membership a free-text box, and had no way to match observed people to the real organization.

Result: Eight page versions and nine studies of the team summary strip, ending at a ship candidate. The review never happened; its best ideas fed later landing and Teams work.

Next: Write the Outcome saying c100, c92 and c103 took the work over, then close it.

A switch between dollars and tokens taught us the table needed both columns.

Why: The cost page showed only dollars. Dollar figures are partly estimates while token counts are measured, so we wanted a switch between the two.

Result: Built in the product, then pulled back the same day to be worked out as a mock first. It never shipped; a later redesign showed both units side by side instead.

The hand-built rule kit became a short list of ready-made policies, chosen by the frameworks you must meet.

Why: Every control had to be hand-built from rules, conditions and actions. That was more setup than an operator should ever have to face.

Result: A catalog of 17 ready-made policies, each switched on with a toggle and driven by the compliance frameworks you choose. It replaced the controls page in the product.

Next: Nothing left to build; move its finished Outcome to the history and close it.

Three overlapping pages were mapped, and one small editing card made it into the product.

Why: Several people had built overlapping dashboard pages for controls, policy and compliance at the same time. The numbers disagreed and the same table appeared twice.

Result: A clear map of the overlap, a ranked list of quick fixes, and an edit-in-place card for controls that shipped to the product. The deeper redesign went to the next cycle.

Next: Nothing left to build; write the Outcome and close it.

A quick walk through the dashboard, room by room, before the redesign started.

Why: We wanted a quick, honest picture of where each page of the product dashboard stood: working, restyled, designed, or polished by hand.

Result: A 22-row table, made in one sitting. Every page worked and wore the new look; five had a design pass; none had been fine-tuned by hand.

Making partners insiders: research, a portal, two tracks and a real weekly digest, waiting on four decisions.

Why: Build partners were about to plug Qpoint into their own systems. They would need to see what we're doing, where it's rough, and feel part of the team.

Result: Research, a partner portal mock, a two-track program and a weekly digest built from real work all exist. The program decisions are still waiting on Mark, so it's parked.

Next: Leave it parked and fix its status note; at pickup, start from the program decisions waiting on Mark. · waiting on Mark's program decisions

Eleven rounds of ideas, and the catalog that won went into the product.

Why: The Integrations page was a list of what might connect someday, and the Teams page had no teams. Neither page matched its name.

Result: After eleven rounds of ideas, Integrations shipped in the product as a catalog grouped by what you want to do, with connected tools showing live numbers. Teams moved to its own cycle.

Testing the order of a partner portal in rough form before anyone paints it.

Why: Qpoint planned a portal for its first build partners. The content was settled, but not the structure: what comes first, and how one page serves an engineer and their boss.

Result: Two wireframes with real content: a shared portal (now, next and shipped, plus known rough edges) and one partner's page with an Engineering / Leadership switch. The review hasn't happened.

Next: Commit the two pages, then review them with Mark when the partner portal comes back. · waiting on design c62's parked portal decisions

A good diagnosis that waited for full attention, until another cycle took the urgent half.

Why: A look at how we use AI helpers across all our projects found the daily work strong but the shared plumbing weak: copied files, no automation.

Result: Nothing was built here. The cleanup half was done by c69; the rest, like shared plugins and automatic checks, waits as notes for a future cycle.

A name and an empty page; the work it named happened next door.

Why: A placeholder for going deeper on the inventory page. Its purpose was never written down.

Result: Nothing was built here. The deeper inventory work happened in c59's last rounds instead.

Eight rounds turned a flat agent list into a page that opens on who's alive, and its agent card shipped.

Why: The inventory page listed agents in one flat table. It didn't say which were alive right now, or what was running unwatched.

Result: After eight rounds, inventory leads with how many agents are alive, how much is watched, and what's at risk. Its agent card shipped into the product on real data.

Next: Nothing left to build; write the Outcome from the last iteration and close it.

Looking at how eleven products list their assets, before drawing our own.

Why: Before drawing an inventory of a company's AI, its agents, tool servers, models and files, we wanted to see how existing products already show such lists.

Result: Eighteen screenshots from eleven products and fourteen lessons, like counts before rows and shadow tools in the same list. The design site's inventory pages used them; the planned brief never came.

Next: Nothing left to build; say the design site used the research, write the Outcome and close it.

qflow started showing what AI agents are doing, live.

Why: qcontrol, Qpoint's agent monitor, streams every AI agent event, but its live view was a table. qflow could show the same stream as moving traffic.

Result: A working first version: agents as pixel figures firing pulses at event types, live or from a sample feed, with filters and a play bar to scrub back. Visual tuning remains.

Next: Commit the experiment, check it still reads qcontrol's live stream, then tune pulse density and spacing by eye.

The pawn got its first badge, sized to the design by checking side by side.

Why: The new pawn needed its first real home: a small card that says what an agent is doing and where, at a glance.

Result: A compact agent card and its "Waiting for your input" bubble now live in the shared library, matched to the design after two side-by-side reviews.

One pixel robot learned to show five moods.

Why: We had pixel-art figures for AI agents but only one picture, so they couldn't show whether an agent was working, asleep or stuck.

Result: The agent pawn now shows five states by stacking art: binary digits while working, zzz when idle, a red burst on error, a bubble when it needs you.

Three compliance pages taken from Figma and made clickable.

Why: Figma had new designs for turning compliance frameworks on and off and seeing their requirements, but nothing to click through.

Result: A frameworks list, an OWASP LLM Top 10 detail page and a findings page now work as mocks, with toggles that update the progress.

Reading the product to find out who it was for, before anyone could be asked.

Why: The dashboard had grown by following the technology. We didn't yet know who it was for, and there were no customer calls to ask.

Result: Reading every page against eleven kinds of buyer showed it fit a hands-on security engineer best. Those guesses now live in market-analyst, and calls have since confirmed most.

Next: Write the Outcome, copy its four open questions to market-analyst, and close it.

Before drawing the map, checking whether anyone needs one.

Why: Incident pages tell what happened in stacked cards and tables. We wondered whether a map of who touched what would help, or was a solution looking for a problem.

Result: Research says yes: Microsoft, AWS, Wiz and others put such maps on incident pages. A design brief is ready. The wireframe was never built.

Next: Build the one incident page from the brief, or park it until incident pages are back on the roadmap.

A Figma table became a real page, and its pieces became shared parts.

Why: A new Figma design turned the policy page from a few summary cards into one table where every rule could inherit or override its settings.

Result: The table page was built from the design, five of its parts and a tab strip joined the shared library, and a real table bug was fixed on the way.

A paint-sample drawer for dark mode, so no color attempt gets lost.

Why: We wanted a softer dark mode, but trying colors meant editing code and losing the last attempt each time.

Result: A color drawer on every design-site page now edits light, dark and a new "subtle" dark side by side, and saves each attempt as a file.

A walk through every room of a scattered product, before anyone started tidying.

Why: Qpoint's product had grown into several separate apps, each built by whoever needed it. Nobody could demo one clear product.

Result: We mapped every app and every screen, and found the new dashboard could only look, not act. The rebuild then happened in later cycles; this one was never closed.

Next: Write the Outcome naming the cycles that carried each goal, send the two leftover goals to a seed and to www's cookie-consent cycle, then close it.

Five new parts, and an AI agent's profile page built entirely from them.

Why: A new page about a single AI agent had been designed, and it needed visual parts we didn't have yet: score gauges, a donut chart, metric cards.

Result: Five new parts, each with a demo, and a full mock of the agent page built from them. It also started the first pixel-pawn figure.

Working out who owns a rule, and letting every standard simply read the answer.

Why: Qpoint's rules page and its compliance page covered the same AI risks but never connected, and nothing said how strict a company wanted to be on each.

Result: A locked model: each control belongs to one policy, which decides what happens when it's broken, and can count toward many frameworks. Five mockups and two wireframes show it.

Next: Commit the pages, which were never saved to git, then write the Outcome and close it.

Every fix moved the problem to another builder, so we stopped using one.

Why: Pushing our work no longer updated the live design site. Builds kept failing on access problems, and the site froze with broken pages.

Result: We stopped building in the cloud. One command builds the site on Mark's laptop and Cloudflare simply serves it. It has worked since September 27.

The site that documents our parts stopped hand-making its own and started using them.

Why: The design site documents our shared parts, yet it still hand-built its own callouts, code blocks, back links and tables instead of using them.

Result: Eleven new shared parts went into the layer, and every hand-built copy on the site was swapped for them. The site now runs on its own system.

Starting over on the right idea, the agent as the one acting, and refining it five times.

Why: The last attempt was built on an app that watched network traffic, and that thinking leaked everywhere. A new agent-first app, qcontrol, made a cleaner starting point.

Result: Five rounds of wireframes for a control plane split into five reader seats, then 50 polished mockup pages, and brochure pages that say plainly what each screen is for.

Next: Write the Outcome and close it; the leftover mockups are optional.

Checking the old app against the new mission showed the old idea still hiding in the new pages.

Why: Qpoint was turning toward governing AI agents, and its existing app had been built to watch network traffic. We needed to know how well it served security, finance and executives.

Result: A page-by-page review and an app split into five seats by role, then a reset: an audit found old traffic thinking in most pages, so seven pages were redone around the agent.

Next: Nothing left to build; say the next cycle took over, write the Outcome and close it.

Two half-stories became one page you can read top to bottom.

Why: The home page and the QControl page each told half of one story, so a visitor had to read both to get it.

Result: The home page is now one long page in nine parts, from the problem to the product to a quick install, built from both pages' sections.

Next: Nothing left to build; write the Outcome and close it.

The cookie banner learned to remember, then left the site.

Why: Website visitors were asked to accept cookies again after every release, because the site kept their answer in a fragile place.

Result: The answer moved into a real cookie the whole site shares. Two months later the cookie banner was removed from the site altogether, so the fix no longer matters.

Next: Nothing left to do: the banner is gone, so record that and close it.

Three agent disasters, each failing differently, make the case that the problem is systemic.

Why: One disaster story could look like bad luck. Three, each going wrong in a different way, show the problem is common.

Result: Three case study pages are live: PocketOS, Replit and SaaStr, and AWS Kiro. The planned index page listing all three was never built.

Next: Decide whether the case studies need an index page, then write the Outcome and close it.

A brief that gave our AI maps a cast of eleven characters.

Why: Our maps of AI sessions used throwaway placeholder figures, with no shared look for agents, tools, files, secrets or policies.

Result: A brief describing eleven characters, the states each passes through, and how policy events look. Later work built the pawns from it.

One document so a newer designer could make the dark site alone.

Why: The brochure site was being drawn in light mode, and a junior designer needed to make the dark version on their own.

Result: A brief they can work from alone: every color value, contrast minimums, and guidance on surfaces and illustrations, with room for their own choices.

One nine-second incident became the story every policy page tells.

Why: Our policy wireframes still used old-style data like where data is stored, when the real risk is now AI agents reading secrets and running destructive commands.

Result: The policy wireframes now tell an AI agent story: six agent policies, and one real incident traced second by second. Good enough for demos.

Nine seconds, one API call: the website learned to show the problem before the product.

Why: Before pitching a product, the website needed a page explaining the problem: AI agents act on their own, and security tools can't see them.

Result: A page called The Problem went live with the PocketOS story, where an agent deleted a company's database in nine seconds. Mark's planned design pass was never recorded.

Next: Decide whether Mark's hand design pass still matters; if not, close it as absorbed into the case studies and the one-page home. · waiting on Mark's design revision pass

A one-image Illustrator design became the website's AI agent story.

Why: Qpoint's story had moved to AI agents, but the website still spoke to security buyers. Mark drew a new five-part page for the agent story in Illustrator.

Result: The drawing became a live QControl product page with all five parts, and the home page was rebuilt around the same story. Polish and dark mode were left open.

Next: Write the Outcome and close it; carry the leftover polish, like mobile and dark mode, into a new cycle if it still matters.

The map stopped replaying recordings and started watching a real agent work.

Why: qcontrol had started reporting which MCP servers and tools an agent uses, but the map ignored those events and could only poll for updates.

Result: The map now updates live as an agent works: a bridge streams qcontrol's events to the browser, and MCP servers, tools, files, hosts and AI providers appear as they're used.

The website stopped keeping its own copies and joined the shared library.

Why: Qpoint's public website kept its own copies of 14 components that already lived in the shared component library, so every change had to be made twice.

Result: The copies were deleted and the website now uses the shared library. The work reached the main branch, but the record was never finished.

Next: Nothing left to build; tick off the checklist, write the Outcome and close it.

A company's MCP servers and the agents that call them, drawn the same way every time.

Why: We needed clean, repeatable pictures of how a company's MCP servers are used and who calls them, without waiting on live data.

Result: Three map views of a six-server fleet: the roster, servers sized by use, and who calls each one. The sizing doesn't show in the captures, and nothing is committed.

Next: Check that busier servers really draw bigger, then commit the experiment and write the Outcome.

Five ways to tell one product's story, built side by side so the best could be picked.

Why: QControl had strong proof, a real agent incident and a clear architecture, but no product page for security leaders, and the best way to tell its story was unknown.

Result: Five one-page brochure wireframes tell the same product five ways: the nine-second incident, the blind spot, the architecture, the cost of trust, and a competitor's layout. A mockup followed.

Next: Write down which of the five stories worked best, then close it.

One real nine-second incident became the test case for every agent policy page.

Why: Qpoint's policy wireframes still told old stories about data residency and vendor lists. A real incident, an AI agent deleting a production database, showed agents need their own rules.

Result: Three wireframe pages, overview, violation and remediation, walk through that incident second by second, with six agent policies and a trust score that falls as the agent misbehaves.

Next: Nothing left to build; mark it completed and move it to the history.

Little standing figures, tipped up so an overhead camera can see their faces.

Why: Voxel characters are built standing up, so from straight overhead you mostly see the tops of their heads.

Result: A Flatland camera keeps the overhead view but tips the voxel characters up to face it. It is written but uncommitted, and was never captured.

Next: Check Flatland in the inventory map, commit it, take one top-down against Flatland screenshot and close it.

Every inventory page learned to say what it is about before showing the table.

Why: The inventory wireframes held the right data, but most detail pages read as piles of facts rather than the story of one agent, model or key.

Result: A new wireframe set: an overview, 11 list pages and 11 detail pages that each open on what matters, plus code repos as a new type. The final review never happened.

Next: Check the pages still build, write the Outcome, and close it.

A cast of characters for an artist to draw, written down and then left waiting.

Why: The things Qpoint tracks, like agents, models, tool servers and API keys, all look like "some machine" in tables and diagrams, so people mix them up.

Result: A first-pass brief gives a pixel artist one character for each tracked thing, with states like new, sensitive or exposed. No artist feedback or sketches followed.

Next: Nothing left to build here; say that Pixel Pawns on the design site carried the idea on, write the Outcome and close it.

c9's ideas held up against the industry, combined into one overview.

Why: c9's ideas were new, but nobody had checked them against how established security dashboards greet you when you first open them.

Result: Scored c9's three overview pages, kept the best part of each, and built a new overview that points at the few hotspots carrying the most risk.

Next: Nothing left to build; mention the second version in the Outcome and close it.

A careful plan to design in Figma first, overtaken by building straight in code.

Why: The product was turning toward AI, and Figma had drifted away from the code. The plan was to rebuild a clean Figma library first, then redesign the dashboard there.

Result: A thorough plan and several prep lists, but the Figma work never happened. The redesign went straight into code instead, in later cycles.

Next: Write an Outcome saying the plan was never followed because the redesign went code-first, then close it.

From one agent's session to every agent in the company.

Why: A session map shows one agent. Security teams also need the company-wide picture: which agents were active, which code and files they touched, and which tools they called.

Result: A company-wide inventory map works on invented data from a small team to a global enterprise, plus a focused map for each kind of item. Judging density is still open.

Next: Look at the enterprise and global maps, decide where repositories and files need summarising, then write the Outcome.

We wrote down how to map a company's AI, and a week later qmap drew it.

Why: qmap could show one AI session, but not a whole company's AI: which agents were active, what code they touched, and which tools they used.

Result: A plan and a sample data set for that company-wide map. qmap built it a week later, exactly to the plan, so the design side was done.

The dashboard tried to be a lantern instead of a ledger.

Why: The c6 dashboard proved the data exists but left the security person to work out what mattered. It was a ledger, not a lantern.

Result: Redrawn pages that lead with what matters, why, and where to look next, for the home, security and every inventory type. c10 took them forward; the cycle was never closed.

Next: Write the Outcome, say that c10 did the comparison work, and close it.

A careful plan to bring qmap's session map home, waiting on a signal that never came.

Why: qmap's 3D map of a live AI session lived only as an experiment. We wanted it as a real page on the design site, without copying unstable code.

Result: A plan only. It says how to bring the map over cleanly, and waits for qmap to settle first. qmap moved on, so the plan was never carried out.

Next: Write an Outcome saying the qmap gate never cleared and the plan stays as reference for c101, then close it.

A brief became a working prototype that turns noisy traces into a readable story, then the idea moved on.

Why: A brief from c38 described a screen that shows how many small, noisy events become a short readable story. It needed to become something real to try.

Result: A working prototype shows the idea with sample sessions and can read a local qcontrol feed. Its open questions were never answered, and the idea moved into later work.

Next: Write a short Outcome saying the idea moved into the session pages and the prototype stays as reference, then close it.

A scripted ten-second session, so the map could practise growing.

Why: Before wiring up real live sessions, we needed to rehearse how a map grows over time: things appearing, lines piling up and phases changing, without the layout jumping about.

Result: A repeatable ten-second replay of an invented agent session plays through four phases on the map, and can be paused, rewound and scrubbed. The Outcome was never written.

Next: Write the Outcome, including whether the replay should move into the library, and close it.

The map's plain shapes met their first hand-made characters.

Why: qmap's simple shapes were fine for layout tests. The next question: could hand-made 3D characters stand in for them and still read clearly on the map?

Result: Twelve voxel models load, scale and light correctly, and a copy of the runtime map uses a voxel Manager for its main process. The recommendation on next steps was never written.

Next: Write down whether voxel characters stay in the experiments or move into the library, commit the loader later cycles already use, and close it.

Our block-art editor became a part you can drop into any page, and the design site shows it working.

Why: qpixel, our block-art editor, was a full web app, unlike our other drawing tools, so other projects couldn't drop it into a page.

Result: qpixel is now a small library any Vue project can import, and the design site shows the full editor working live.

All our design history on one line you can scroll, with each piece opening right where you are.

Why: Our design history was spread across the archive, the history pages, cycle records and git, with no single place to see what happened when.

Result: A first timeline: archive items and milestones on one scrollable line, with filters and zoom, and the item's page opening right below it. Detail pages and git history were left for later.

Before building anything, we wrote down six screens that would make qcontrol's evidence easy to trust.

Why: qcontrol's engineering was moving fast, but how to show and explain what it sees was still mostly in people's heads.

Result: Six short design briefs, plus shared rules for showing confidence, sources and live state. One of them became a working prototype in the next cycles.

We followed the missing baton through every handoff and found it was never passed.

Why: The new map of an agent run showed network activity live, but runs that only touched files never appeared. We needed to know where those events were lost.

Result: Found it: qcontrol wasn't sending file events out at all, so our map code was fine. The map is now described honestly as a network map, with test data for the rest.

Four rounds of reading qcontrol's code found the stream we could draw, and a new qmap cycle drew it.

Why: qcontrol watches what programs and AI agents do on a machine. We wanted to know whether that stream could feed our map and traffic pictures.

Result: Four rounds of research found the way in, qcontrol's event stream, and planned a map of one agent run. It was built as a new qmap cycle. One early mistake was caught and corrected.

Next: Nothing left to build; write a short record pointing at where its plan went (qmap c22 and c37) and close it.

bob-wire learned to sketch diagrams, not just boxes.

Why: Design had briefs that needed diagrams (maps of what connects to what, flows, before and after), but bob-wire could only draw boxes, tables and forms.

Result: bob-wire learned a simple diagram language and drew six test pages with it. A rerun method lets the same briefs be redrawn as the skill improves.

Copy and paste stopped being a trick and started working like copy and paste.

Why: Copy and paste in qpixel worked like a trick of the select tool, so moving part of one saved drawing into another was awkward.

Result: Copy, cut and paste now have buttons and the usual keyboard shortcuts, and the clipboard survives switching drawings. Built and tested, but uncommitted and not closed.

Next: Commit the finished copy and paste work, write down what shipped, and close the cycle.

A running program's footprint, drawn as one map.

Why: qcontrol, Qpoint's runtime monitor, records every file, process and connection a program makes. We wanted to see one program's session as a map, not a log.

Result: Recorded sessions now draw cleanly with parts qmap already had, through a runtime view with its own defaults and a small bridge that feeds it live. Very file-heavy sessions still need trimming.

Qpixel drawings can leave the editor as sharp vector images, and a test sheet keeps them sharp.

Why: Qpixel could only export text files. Web pages and design tools need vector images, and drawings now mix blocks, line characters and words.

Result: SVG and PNG export were built, with a merged-shapes option and a test sheet that checks edges stay sharp. The code is uncommitted and the cycle was never closed.

Next: Commit the finished export code, write down what shipped, and close the cycle.

A parallel attempt at SVG export that left nothing behind; c4 carries the work.

Why: Probably the same goal as c4, exporting drawings as vector images. The folder is empty; c4's prompt says another agent was working c3 in parallel.

Result: Nothing was recorded here. The SVG export work was planned and recorded under c4 instead.

Next: Nothing to build; delete the empty folder or note in the history that c4 replaced it.

A block painter learned to draw boxes, arrows and words.

Why: Qpixel could only paint blocks. To draw diagrams it needed lines, arrows and a way to type labels.

Result: The editor gained line and arrow characters, a text tool, nudge buttons, and select, copy and paste. Its colors now match Qpoint's design system.

A sketch pad became a tool: it can now show its work and keep it.

Why: Qpixel, our editor for drawing pictures out of text characters, was hard to use: the grid was faint, there was no preview, and nothing could be saved.

Result: The editor became a working tool, with a brighter grid, a live preview, a recolor tool, brush sizes, size sliders and a library that keeps drawings in folders.

A bare terminal got a welcome screen, and the tools built for it became a project of their own.

Why: People trying the qcontrol demo saw a bare terminal. Nothing told them their AI agent was now being watched, or that this was a Cisco and Qpoint product.

Result: A finished welcome screen for the demo terminal, drawn in block characters with a Cisco plus Qpoint logo, and notes for Jon to build it. The toolkit behind it became qpixel.

Two crowded diagrams of qcontrol, redrawn plainly; nothing says why.

Why: Not recorded: the prompt file is empty. The files suggest a need to explain simply how qcontrol, the tool that sandboxes AI agents, is put together.

Result: Two crowded architecture diagrams of qcontrol were redrawn as two plain ones: three commands talking to an engine, and the four steps a watched call takes. Nothing says where they were used.

Next: Ask Mark what the diagrams were for, write a short record of them, and close it. · waiting on Mark's answer

Pictures instead of tables: three security questions, each answered by a drawing.

Why: Qpoint records what AI agents do (sessions, models, keys, tools, files) but showed it only as tables. Could pictures make it clear to a security team at a glance?

Result: Four working sketches each answer one security question with a picture: what did this agent touch, who connects to which model, which tools are exposed. Later cycles carried them on.

An AI agent's working session, drawn as one map instead of a table.

Why: AI agent monitoring records every server called, file touched and host contacted, but shows it as tables. A map could show the shape of a whole session at a glance.

Result: One agent session now reads as a map: the agent in the middle, with rugs for MCP servers, skills, files and outside hosts. Lines also took charge of their own look.

Next: Write the Outcome (the session map works and lines now manage their own look), then close it.

qflow tried drawing what AI agents do, not just network traffic.

Why: Qpoint's AI monitoring data (sessions, agents, models, API keys, tools, files) was shown only as tables. Could qflow's moving pictures make it readable for security teams?

Result: Seven views in one page: an agent session in three forms, an org-wide map, a map of tools, and two inventory views. qmap later built a 3D companion.

One command put every wireframe on the web.

Why: Developers wanted to look at the wireframes on their own time without running bob-wire on their own machine.

Result: One command now publishes every wireframe to a web address. It was meant as a stopgap until bob-wire could move to Cloudflare like the design site.

The whole dashboard, in grey boxes, with menus that work.

Why: c5 defined what to track about AI agents. The team needed a clickable dashboard to walk through, not just a list of fields.

Result: A 25-page clickable wireframe: home, security, alerting, settings, and a list and detail page for all ten inventory types. A second pass made the overview pages say what matters.

The turn from watching data leave to watching AI agents work.

Why: The dashboard was built around company data leaving for vendors. Qpoint now wanted to show what AI agents do: who ran them, what they touched, and whether it was safe.

Result: A list of everything Qpoint can observe in an agent session, ten kinds of inventory item with defined fields, and a first wireframe of the session inventory.

A prototype's raw readout became a page you can browse.

Why: Qpoint could already see AI agents' traffic (sessions, models, tokens, cost) in a rough prototype, but nobody had designed how to present it.

Result: Three linked wireframes: all agents, one agent's sessions, and one session in detail. It fed straight into c5's bigger rethink; the Outcome was never written.

Next: Write a short Outcome saying the three agent pages fed the c5 rethink, then close it.

Lines on the map learned to say which way the data goes.

Why: A dashed line only hints at which way data flows, and the hint gets lost when lines cross or the camera turns. Arrows make direction obvious.

Result: Four arrow styles were compared and two decorations joined the library: cone arrows, spread along the line or sliding with a trail, and a travelling glow. Both are optional and tunable.

Next: Nothing left to build; add it to the history and close it.

The map of one connection, rebuilt so every part of it can be tuned.

Why: The first single-connection map had its settings hard-wired. With c18's control panel in place, we wanted it rebuilt so every part of its look could be tuned and saved.

Result: The single-connection map was rebuilt on the settings system, with its own defaults, five context groupings, and new dials for line thickness, label size and rug padding.

Next: Nothing left to build; add it to the history and close it.

One control panel that builds itself, used everywhere afterwards.

Why: Every qmap experiment built its own control panel by hand. We wanted one panel that draws itself from a list of settings, usable in qmap, qflow and the design site.

Result: One configurator now builds a full control panel from a typed list of settings and exports only what you changed. It became the shared control set in our component library.

Next: Nothing left to build; add it to the history and close it.

A first sketch of a map for one connection, soon redrawn.

Why: A connection's detail page needed a small map at the top: just the two ends of one connection, with the option to show where each end lives.

Result: A first version shipped: two larger things, one line, and separate context switches for each end. The look was left unfinished, and c19 rebuilt it from scratch.

Next: Nothing left to build; record it as replaced by c19 and close it.

A map legend for the roads data travels between systems.

Why: Qpoint needed a way to show the paths data takes between systems, and how sensitive the data on each path is.

Result: Three linked wireframes: a health overview, a sortable list whose rows open into cards, and a detail page with settings. Finished, but never moved to the history file.

Next: Nothing left to build; move it to the history file and close it.

A request written down and handed straight to the next cycle.

Why: Qpoint wanted a new kind of record, the "dataflow": the path data takes between two places, with what kinds of data travel along it.

Result: Only the request was written here. The next cycle, c3, copied it word for word and built the pages.

Next: Close it as replaced by c3, which copied its request and built the pages.

A Figma policy page rebuilt from seventeen parts already on the shelf.

Why: The security overview had a mock, but policies, the rules a security team sets and watches, had no reference pages yet.

Result: The policy page was rebuilt from a Figma design using seventeen existing parts and nothing new. The listing stayed empty until a later cycle. A repeatable Figma-to-page method came out of it.

The design site learned to show whole pages, starting with the security overview.

Why: The design site showed components one at a time but never a whole page. The engineer building app pages had no clean example of how the parts fit.

Result: The design site gained a Pages section. Its first entry rebuilt the security overview from shared parts, and five health and severity parts moved into the shared library.

A friendly tour for newcomers, written once for design and never rolled out further.

Why: Each project's instructions were written for AI helpers: what and how, never why. Someone new had no friendly way to learn what a project is for.

Result: A /tour command now walks a newcomer through the design project: its purpose, its neighbours, key ideas and common tasks. The rollout to other projects never happened.

Six drifting copies of the same instructions became one master with room for local habits.

Why: Six projects each kept their own copy of the instructions for running cycles, and the copies had drifted apart. Updating them meant six edits and guesswork.

Result: All six projects now share one set of cycle instructions, kept in design, with room at the bottom for each project's own rules. qflow and qmap moved to the same layout.

Two drawers of overlapping parts, sorted, and the newer one relabelled so its name says what it holds.

Why: The shared library had two overlapping families of data components, and nobody could say which to use. One family was called DataMachine, a name that said nothing.

Result: All 22 data components were sorted into replaced, keep or look again. DataMachine became DataMetric in all three projects, and a new page explains which to use.

The tools that build every demo got demos of their own.

Why: The design site documented only five of its eleven demo-building tools. The control-panel pieces had no page, so people building demos could not find them.

Result: All eleven tools now have a working demo on the design site, on two pages kept off the public component list.

The dots got real names from qmap.

Why: qflow's sample traffic was bare addresses. Real data, like qmap's map of apps, services, vendors and datasets, has names, kinds and tags.

Result: qflow now runs on named sample actors coloured by kind, in five sizes from tiny to large, plus one built from raw addresses. Built in March, never formally closed.

Next: Nothing left to build; write the Outcome and move it to the history.

Four laptop-only projects got ready for the web, with a brief for the person who would host them.

Why: Four of our internal projects ran only on a laptop. Teammates in sales or engineering had no way to simply open them in a browser.

Result: All five repos were made ready to build as plain web pages and merged, the shared library was published, and Jon got a hosting brief. Going live finished in a later cycle.

A habit of tasting while cooking became principle eight, with a page that shows what still needs tasting.

Why: We already built each shared part by using it on the design site first, but only by habit. Nobody could see which parts had really been tested.

Result: It is now principle eight: building a part and documenting it are the same act. All 87 parts were audited, a coverage page shows the gaps, and the worst were filled.

Two experimental libraries got real names and live pages on the design site.

Why: Our two visualisation libraries, a 3D network map and a 2D traffic flow, were nearly ready but undocumented and hard to use outside their own projects.

Result: Both got proper package names and live demos on the design site: an overview of when to use which, and a page for each.

A plan to show real traffic that stayed a plan.

Why: qflow only ever showed made-up traffic. The idea was to show real traffic in the Qpoint app: qflow on top, the existing traffic inspector below.

Result: Only a plan was written: a feed adapter, a split-screen page, and questions for the inspector's owners. Nothing was built. c12 later built a live feed for a different source.

Next: Close it as replaced by c12's live feed, unless the split screen with dev-tools is still wanted. · waiting on answers from the dev-tools owners

The names on the dots became readable.

Why: Labels were stuck under each dot in a hard-to-read grey, and the control panel had grown into a wall of repeated code.

Result: Labels can sit on any side, in any colour, on a rounded background. The panel was rebuilt from five reusable controls. Built in March, never formally closed.

Next: Nothing left to build; write the Outcome and move it to the history.

The layouts got honest names and learned to make room.

Why: As dots grew with traffic they began to overlap, and the layout called "arc" was really a full circle.

Result: A true arc now packs destinations by size, the old layout is honestly called radial, and dots re-space themselves once they have grown enough to crowd.

A rule about where things go: everything you can see goes in the shared pantry.

Why: The shared library already held product-specific parts, and the urge to 'keep it pure' cost more than it saved. The product also ran an old copy of the demo tools.

Result: Settled: every visual part lives in the shared library, and only parts wired to live data stay in a project. The product dropped its six old demo-tool copies.

One cycle after giving the card an open shelf, we saw only one thing ever went on it and built that thing in.

Why: The space beside the policy card only ever held a violations table, so leaving it as an open slot made every page rebuild the same table.

Result: The violations table is now a shared part of its own, and the card takes a list of samples and draws the table itself. A policy page can use the table alone.

The policy card's frame came off so allow-list cards could wear it too, in a new light blue.

Why: The policy page needs cards for allowed apps, datastores and vendors that look like policy cards but hold different content. That look was locked inside the policy card.

Result: The border, shadow and ribbon became their own wrapper with five colour states, including a new light-blue one for allow-lists. The policy card uses it and looks the same.

An alert rule written as a sentence went from drawing to shared part, and its sentence pieces turned out to be useful everywhere.

Why: People need rules that say when a policy violation should raise an alert, how, and how often, set up in a way that reads like a sentence.

Result: An alert rule card was built to the design, then its sentence pieces were moved into a shared set of their own so filters and other rules can use them.

The policy card learned to carry its violations beside it, just as the security design drew it.

Why: The security design shows each policy card with its violations table beside it. The card had no room for that, and the little data-flow picture had no shared part.

Result: The card gained a space beside it for the violations table, and a new part draws the data-flow picture: a dot, a tag like PII, and an arrow.

The design site started to look like the brand it teaches, a step at a time, before later rebuilds took over.

Why: The design site explained the brand but did not look like it. Mark wanted to bring the Qpoint look to it in steps, designed first in Figma and Illustrator.

Result: Component pages gained three view modes that remember your choice, examples became easier to read, and a resize bug was fixed. Later rebuilds replaced most of the look.

A saved paper with nothing written around it, which turned out to matter seven months later.

Why: Mark saved a 2005 design-method paper by Axel Roesler, his old thesis chair, about the hard leap from understanding people's work to first design ideas.

Result: Nothing was built and no notes were written. Seven months later the same paper became the top-ranked source behind our design method.

Next: Ask Mark whether it was meant to be more than a saved paper; if not, close it as carried on by the sources work. · waiting on Mark's answer

Pulses learned which way they were going.

Why: Pulses were flat white lines that blinked on and off, with no sense of which way the traffic went.

Result: Each pulse is now a bright head with a fading tail, travelling from sender to destination. The destination flashes when it lands, and pulses stay attached when dots move.

The picture started filling itself in as traffic arrived.

Why: Earlier cycles replayed a fixed log. Real traffic is fluid: new senders and destinations keep appearing, and some get much busier than others.

Result: Dots now appear as traffic arrives and grow with activity, and the view zooms itself to fit. Pulse lines can be straight, angled or curved.

Reading 36 product files turned the library's hardest part into a guide anyone can follow.

Why: The shared table is the most complex part in the library and is used across the product, but its docs were a thin demo unlike real use.

Result: Eight table demos now use realistic data and line up properly, and a new guide walks from the simplest table to how the product really builds one.

Mark wrote down why the shared library beats the old playground, so colleagues could see the logic.

Why: Colleagues needed to understand why screen parts now live in one shared library, and why the old practice playground kept breaking.

Result: A new Layer page explains the shared library, what it gives every project and how it beats the old way. The icon docs were tidied and a table bug was fixed.

Moving to the shared library broke the app in small ways; fixing them made the library better.

Why: The app had just switched to Qpoint's shared component library, and things broke: a failing build, missing menu icons, crashes and a dial drawn wrong.

Result: Every break was fixed and the app ran without errors. Improvements found in the app's own copies were moved back into the shared library.

A design tool handed us a messy first draft of the policy card, and a cleaned-up version became a shared part.

Why: We had Figma designs and a tool that can read them, but no tested way to turn a Figma component into a working part of our shared library.

Result: It worked: the policy card came out of Figma as a real shared part, with four sizes and two states. The output needed tidying, and the Figma-to-code link was left for later.

A page of marketing blocks laid out for Figma, and then the Figma work never came.

Why: The marketing site's twelve building blocks existed only in code, so nobody could lay out or review a page in Figma.

Result: A plain page showing all twelve blocks was built, ready to send to Figma. The Figma library and its links to the code were never made, and the cycle was paused.

Each project got a phone list of its neighbors, so work can cross between them.

Why: Qpoint had eight or more projects, each expert in something, but none knew what the others offered. Using two together meant knowing where everything lived.

Result: Each of the four main projects now lists its neighbors: what each is for, when to use it, and where its data lives. AI sessions can now borrow across projects unaided.

A landing page for security buyers, drafted in words and paused before it was built.

Why: Sales calls showed security buyers bring urgency, while engineering buyers bring interest but rarely buy. The new policy dashboard designs gave us a story for security teams.

Result: A first draft of the page's words exists, in seven sections, with two dashboard designs as proof. The page was never built, and the cycle was paused.

A plan to put Qpoint's screens inside AI chats, left on paper.

Why: Qpoint wanted an AI assistant inside its app, and the same small screens to show up inside outside AI tools like Claude and ChatGPT.

Result: Research only: a recommended approach and a plan for sharing components. Nothing was built, and the app it targeted is no longer used.

Next: Close it as abandoned: the app is no longer used; if in-chat screens come back, start fresh in the current product.

A calm control room that points at the problem when something breaks.

Why: Security teams needed one place that shows whether things are healthy and, when they aren't, what is wrong, who is involved and how to fix it.

Result: The "Situation Room" became a reusable pattern. Its first instance, Policy Compliance, got three wireframes and one polished mock. The cycle was never formally closed.

Next: Nothing left to build; write a short Outcome saying the pattern carried into c13, then close it.

One long page of patterns became a grouped index of short pages.

Why: The Patterns page had grown to 18 patterns on one long scroll, and its index listed only 12 of them.

Result: Patterns now live on short pages by group, with an index laid out like the components index, and one page that still shows all 18.

A rename fixed a naming clash, and seven more website blocks joined the shared kit.

Why: The kit's "content" group clashed with a plugin that strips that word from names, and seven more website blocks still lived only in the website.

Result: The group was renamed "prose", which fixed the clash. Seven more blocks moved into the kit, so the website keeps no copies of these twelve, and all have demos.

A video to show the team how design works here: planned in February, never recorded.

Why: The team had never had a proper look at the design side's thinking and tools. Engineers and sales each needed different pieces to use them on their own.

Result: Not made yet. There is a plan for a short recorded video in three parts, a list of who it's for, and an open question about how it should start.

Next: Ask Mark whether the video is still wanted; if yes, park it with a pickup note, and if no, close it. · waiting on Mark's answer

A 2007 thesis turned out to describe how Qpoint already worked, so we wrote it down.

Why: Mark's 2007 thesis on how designers tackle messy, open-ended problems already matched how Qpoint worked, but nothing said so out loud.

Result: The thesis became Qpoint's design method: a written guide, a /method page, a writing rule ("form the problem, then solve it"), a way for AI helpers to read it, and draft marketing lines.

Six of the website's building blocks moved onto the shared shelf.

Why: The website had its own building blocks for marketing pages, like grids, headlines and numbered steps, that other projects could use too.

Result: Six of those blocks moved into the shared kit under two new groups. The website now uses the shared versions, and each block has a live demo.

The app threw out 51 duplicate parts and the design site learned to demo most of the kit.

Why: The app still kept its own copies of parts already in the shared kit, and only 12 of the kit's 43 parts had a working demo.

Result: The app dropped 51 copied files and now uses the shared kit. The design site gained 20 demos, so 32 of 43 parts can be tried live.

The shared parts moved out, and the design site became an honest customer of its own kit.

Why: The style guide was doing three jobs at once: shared parts, brand notes and a website. Its settings needed special switches to know which job it was doing.

Result: The shared parts moved into their own project. The design site now uses them like any other project does, so it feels the same problems everyone else would.

The style guide became the shared kit every Qpoint project borrows from.

Why: Our website and our app each kept their own copies of the same buttons, colors and styles, so every change had to be made twice.

Result: The style guide became a shared kit that other projects plug in with one line. Ten shared parts came first, and nothing in the projects had to be renamed.

Two readers of the same call, each better at something; use one as background for the other.

Why: Avoma, the meeting recorder, started writing its own notes on every call. Were they worth adding to what Claude already pulled from the transcripts?

Result: Yes, as a supplement. Claude reads insight better; Avoma's notes catch deal details like next steps and blockers. The plan to combine them was built in March.

Next: Nothing left to build; correct the pickup note, write the Outcome and close it.

Don't build a second path; send Sagetap calls down the one that already works.

Why: Sagetap, where buyers hold evaluation sessions with vendors, sent a second stream of prospect calls, but as rough transcripts with no names, dates or company.

Result: Sagetap calls now go through the same recorder as every other call, and the dashboard tags each call with its source. One call ran end to end; a second waits.

A tool that finds the patterns already in use, and the app's first four on the page.

Why: The Patterns page covered only the website. The product app repeats its own combinations across 20 pages, and finding them was all done by hand.

Result: A reusable scanning tool now finds repeated combinations in any project. It found five in the app; four went onto the Patterns page, live and copyable.

Parts started being shown together, the way pages really use them.

Why: Single demos show one part at a time. They don't show how parts fit together, which is how the website actually uses them, over and over.

Result: A new Patterns page shows three common combinations live, each with code you can copy to start a new page.

From a fixed report to a question you can ask.

Why: The batch analysis gave a fixed report. With 19 calls in, the team wanted to ask its own questions and get answers backed by the calls.

Result: A chat command now answers questions about the calls, citing the company, the date and the customer's own words. Its first test sized up one prospect's interest.

Tidy both ends: count only what customers said, and give every company a page.

Why: The pipeline worked, but some calls had missing or wrong findings, and the dashboard didn't always show the right things.

Result: Findings now come only from what customers themselves said, with how urgent they are and which pitch landed. Company pages were added. The planned full re-run never happened.

Next: Close it: the dashboard work stays, and the re-run it planned was done later under the new questions. · waiting on Mark's OK to close (the pickup note recommends it)

The first grey-box drafts of Qpoint's rules, queue and vendor screens.

Why: Before Qpoint had a dashboard design, it needed rough first drafts of its three core screens: rules (policies), a to-do queue (triage) and outside companies (vendors).

Result: Three sets of rough wireframes set the layout and navigation that the next cycles built on. The policy pages were drawn twice, the second time leading with action.

A sign-in plan that waits on whether there's anything to sign in to.

Why: The call dashboard was open to anyone with the link. As it grew and got shared, only Qpoint staff with company Google accounts should see it.

Result: Not started. A nine-step plan is written, but nothing was built. It waits on whether the dashboard will be hosted for the team at all.

Next: Decide whether the team will reach the dashboard at a web address; if yes, follow the sign-in plan, if not, close the cycle. · waiting on the hosting decision

The dashboard got Qpoint's look, and nobody wrote down how.

Why: The call dashboard needed to look like Qpoint, with colors, type and spacing set once and reused, rather than styled page by page.

Result: The record never says what changed. Screenshots taken six months later show the dashboard dark, with Qpoint's mark and purple accents.

The dots tried being soft and alive.

Why: All the dots were hard geometric shapes. This cycle tried making them feel softer and more alive.

Result: Five shapes now switch live: circle, square, hexagon, a wobbly blob and a rounded square. Blobs can slowly breathe. Later cycles kept the shapes but stayed with circles.

The component library got documented twice: once for people, once for AI.

Why: The component pages in the app's built-in library were thin and their examples often wrong, and AI assistants had no good way to learn the components.

Result: Over 116 library pages with live examples, plus a catalog, rules and a machine-readable list of 103 components for AI assistants. Done, but never formally closed.

Next: Nothing left to do; app.qpoint.io is no longer used, so move this to the history.

The first pipe: call recordings in, structured findings out.

Why: Qpoint wanted to learn from its sales calls, but they existed only as recordings and transcripts that nobody could compare side by side.

Result: Calls now flow from the meeting recorder through Claude into structured records. The first run listed 79 transcripts and turned one demo call into scored themes, pains and requests.

The dots got names, colours and faces.

Why: Every sender and destination was the same plain circle, so you couldn't tell a payment provider from an internal service.

Result: Dots now have names, shapes and colours: blue senders, green internal services, pink outside vendors with their own icons. Labels can be off, on hover, or always on.

qflow found its hub-and-spoke shape.

Why: The sample traffic was too even, and the layout didn't show traffic's hub-and-spoke shape: many senders in the middle, destinations around them.

Result: Senders now sit in a centred cluster with destinations in a ring around them, fed by busier, more uneven sample traffic. Three grid bugs were fixed and the canvas follows the window.

qflow went from a fixed picture to one you can move around in.

Why: The picture opened zoomed in, in a fixed-size box, with no way to move around it.

Result: You can now scroll to zoom toward the cursor, drag to pan, and fit everything back in view. The canvas fills its space and pulse lines stay attached at any zoom.

qflow got its own home and a clean place to start.

Why: qflow had just been moved out of an older project into a library of its own, and a few bugs kept it from running cleanly.

Result: Fixed a memory leak and a lookup bug, renamed a confusing setting, and set up the first experiment page. No working picture of it survives.

The first time the map was pointed at one problem: a rule being broken.

Why: Different pages need different maps. A page about a policy violation needs a calm, focused view of the offending connection, not the whole interactive map.

Result: The first view preset works: a policy-violation view that draws the offending flows in red as soon as it loads, highlights the things involved and fades the rest.

Fourteen experiments became one map other projects can use.

Why: Fourteen cycles of qmap experiments worked, but other projects couldn't use any of it. The library itself still showed a spinning placeholder shape.

Result: qmap became one component other projects can import: hand it things, connections and a grouping rule, and it draws the map and animates every change. Five bugs were fixed on the way.

AI agents and the people using them joined the map as shapes of their own.

Why: Company traffic now includes AI agents and the people using them, and the map only knew apps, services, databases and vendors.

Result: Two new shapes: AI agents as a floating crystal, and users as a simple person figure. Test scenes add AI vendors like OpenAI and Anthropic, and the map can group by user.

One map, three ways to read it: where things run, what they are, and where in the world.

Why: The map arranged things only one way at a time. People need to see the same estate by infrastructure, by kind of thing, or by place.

Result: Three view modes share one map: topology (the default), group by tag, and geography by continent, country, region and city. A switch moves between them.

When the data changes, the map shows you exactly what left, moved and arrived.

Why: Real data changes all the time. Redrawing the whole map on every change would be jarring, and you would lose track of what moved.

Result: The map works out what changed and animates only that, in four steps: leavers fade out, tiles reshape, movers glide, newcomers appear. It holds up from 7 to 300 things.

Layout code that had grown tangled over five cycles was replaced by one clean engine that packs boxes inside boxes.

Why: Layout code from five cycles had grown tangled: positions, 3D coordinates, collisions and label sizes all mixed together, so it was hard to reason about.

Result: A clean layout engine works on a simple grid, packs groups inside groups from the inside out, then hands positions to the 3D scene. Test scenes from three things to hundreds check it.

Four ways to pack apps into their boxes, switchable live, on the way to a clean restart.

Why: The six-layer view from the cycle before wasted space and stretched into long strips. Layout needed to be compact, and easy to compare.

Result: Four packing methods (grid, spiral, circle packing, sunflower) can be switched live, and things glide between them. The next cycle still rebuilt layout from scratch.

A view of where software actually runs, six layers deep, that got too tangled and was started again.

Why: Grouping by tags doesn't answer "where does this actually run?" The map needed a second view: cloud, region, cluster, namespace, node, pod.

Result: A topology view nested six levels of ground tiles, with an outside zone for vendors and a switch back to the tag view. Two layout systems made it too complex; the next cycle started again.

qmap became a photo studio: swap the data, hide what you don't need, take a clean shot.

Why: Design work needed clean pictures of qmap, with different data and different amounts on screen.

Result: Test data moved into files you can swap, from the full vendor set to a single vendor. Switches hide labels, rugs or shapes, and spacing sliders make clean plates.

The map rests flat for browsing and tilts into 3D when you focus on one thing.

Why: Browsing a big map and studying one part of it are different jobs. The view needed to show which one you are doing.

Result: The map now rests flat, like a plan seen from above. Click a thing and the camera tilts into 3D around it while its connections arc out; unfocus and it flattens again.

The camera learned to find what you clicked, tilt to a floor plan and turn in quarter steps.

Why: On a crowded map, finding one thing and what it talks to meant hunting around. The camera also had only one fixed angle.

Result: Click a thing and the camera glides to frame it and its connections; click the background to go back. A slider tilts from 3D to straight down, and buttons turn the map a quarter turn.

The map learned to re-sort itself by any label, and the shapes glide to their new groups.

Why: Groups like team or region were fixed into the data. People want to ask one map different questions: by team, by data center, by how critical it is.

Result: Each thing now carries tags, and a menu regroups the map by any tag. Things glide to their new group while the ground tiles fade and redraw. Things missing a tag land in "unknown".

The map learned to zoom like Google Maps, from one company block down to every app, though most of the plan stayed on paper.

Why: A real company has hundreds of apps. Showing all of them at once is noise; the map needed to zoom like Google Maps, adding detail as you go in.

Result: A test map steps from one company block, to twelve team blocks, to about 166 apps on nested ground tiles. Smooth expanding, merged flows and automatic layout were planned but not built.

Lines appeared between the shapes, showing what talks to what and whether personal data is involved.

Why: With shapes on the map, the next question was the one qmap exists to answer: what is talking to what, how much, and is personal data involved?

Result: Curved lines now join the shapes. Five line styles were built; thickness shows volume, color shows the kind of traffic, and a badge marks personal data. Plain and dashed lines were recommended.

Each kind of thing on the map got its own shape, so an app no longer looks like a database.

Why: On the map every thing looked alike. You needed to tell an app from a database or an outside vendor at a glance.

Result: Four shapes, one per kind: apps, services, databases and vendors, with vendors showing their logo. Each can show as active, highlighted, warning or faded out.

Thirteen ways to draw a border on a 3D map, built side by side, with no winner written down.

Why: qmap, our 3D map of what's connected to what, needed a way to show where each thing lives, like a security zone or a team, without cluttering the picture.

Result: Thirteen ways to draw a boundary were built side by side, from walls and fog to terrain and rings. No winner was written down; later cycles grew the flat ground tiles into qmap's "rugs".