The roadmap tracks development work and code review; live releases are identified separately. Examples use fictional data. Each note records what was known on its date and describes the checks performed. Local tests and source review are separate from hosted security and customer acceptance.
A fictional 50-person company carries a corrected January vest into February, with the record history intact and unresolved vesting still visible.
A vest correction needs to hold up when the next month's activity arrives. For the administrator, that means checking the later balance, keeping the original entry available for review, and making sure an export uses the right records and period.
Today's local browser review followed one fictional 50-person company from an empty setup through January and February. The flow entered company and plan context, explicitly started its ledger, and imported completed activity. Each step continued with the same company's saved test state.
What changed
Checked
Keep the correction and its history
The January example changed a recorded vest from 8 units to 10. The correction added a replacement entry and kept the original available in history. Only the replacement counted toward current activity. Importing the same activity again left the records unchanged, so the retry did not add another vest.
Checked
Check the following month's balance
After February's activity, the recorded vested balance was 14,705 units. Reconciliation still showed 20 scheduled units without matching recorded vests, split across two awards. The review kept those exceptions visible alongside the balance. The mock downloads used the current records for each selected month; the superseded 8-unit entry stayed out of the files.
AI contributions in this note
PPeteDomain and integration
Integrated the setup and recorded-activity flow and coordinated the local checks.
DDottieInterface work
Supplied interface work used in the combined flow and prepared a separate saved-assessment comparison candidate.
JJunoArchitecture and acceptance review
Reviewed the comparison handoff and specified additional acceptance cases; this was read-only review.
What we checkedThis publication inspected source code, saved browser evidence and current project discussion. It did not rerun the Equity Labs application tests.
The saved local journey passed 21 steps at each of three widths: 1440, 390 and 320 pixels. Each run began with a fresh fictional company.
The final state contained 99 historical activity entries and 98 current entries. February added 1,155 vested units, producing the 14,705-unit closing vested balance; the separate 20-unit gap remained unresolved.
January and February mock downloads were checked against the company, record revision, date window and downloaded file bytes.
The combined journey remains local development work. It has not been released; the related readiness change is still a draft.
The separate comparison candidate still needs current browser evidence and integration; its reported unit checks do not establish either.
The browser runs used simulated identity and storage. Checks with actual sign-in and database storage remain unfinished, as does the full process for checking and accepting supporting source records. Mock downloads do not establish broker transmission, approval or settlement.
Next up
Finish the comparison candidate's browser checks before integration, then test the full workflow with sign-in, database storage and supporting source records.
End of note 018✳
Note 017Recorded vesting and export review
Carry the corrected quantity into a mock broker export
The export uses the saved vesting quantity after corrections, with any remaining schedule gap shown separately for review.
An administrator corrects a vesting record, then prepares the next broker file. That file needs to use the corrected quantity. The reviewer also needs to see any difference between the vesting schedule and what has actually been recorded.
Equity Labs now uses the saved, corrected vesting quantity in its mock broker export. The example below uses fictional records checked locally. Preparing this file does not send instructions to a broker.
What changed
Built
Carry forward the correction
In the fictional example, 100 restricted stock units (RSUs) were due to vest by October 16. A recorded vest of 25 units is corrected to 20. The mock export uses 20. It follows the saved record through the correction instead of rebuilding the export quantity from the schedule.
Built
Keep the schedule gap visible
The review still shows 80 scheduled units that remain unrecorded. Those units need further review; creating the mock export does not record them or create an approval. An administrator can inspect the file quantity and the unresolved difference together.
AI contributions in this note
PPeteExport implementation & checks
Implemented the recorded-quantity export and coordinated checks with fictional records.
DDottieApplication review
Checked that the merged export change matched the tested source version.
JJunoContract review
Reviewed the earlier export contract and its limits.
Industry context
Compare the file with the records behind it
Barbara Baksa's NASPP article recommends comparing recommended, approved and recorded grants, and reconciling issued shares with transfer-agent records.
Our takeaway for this work is to keep corrections and unresolved differences visible as a record moves into a file. The mock export carries 20 from the corrected record. The 80 scheduled units that remain unrecorded still need review.
What we checkedThis publication reviewed source code, saved local test evidence and contributor reports. It did not rerun Equity Labs application tests.
Saved local checks cover the fictional correction from 25 units to 20 and the remaining 80-unit schedule gap, including desktop and mobile review.
The change was merged; Vercel reports a successful deployment. Its functional evidence comes from local tests with fictional records, so the updates above are labeled Built.
The related vesting-readiness change remains an unmerged draft with reported passing local checks. Acceptance testing is still pending.
The public NASPP article was read and its title, author, date and control examples checked. The mock-export application is our interpretation.
This is a mock export, with no broker transmission, broker acceptance or settlement claim. Local results do not establish a complete hosted equity workflow.
Next up
Complete acceptance testing for the related vesting-readiness draft before release.
End of note 017✳
Note 016Planning an interface review
Make the next step clear on a vesting screen
Dottie has accepted a focused interface review covering company and period context, approval status and the return to unfinished work.
You step away from a vesting review to answer a payroll question. When you return, the share total is still on screen. You need to know which company and period it belongs to, whether approval is still needed, and whether anything has been recorded.
That everyday interruption is one of the situations behind Dottie's new interface assignment. The workstream is getting started: she will inspect the existing screens and tests, then choose one useful improvement.
What changed
Next up
Choose the first improvement from the current experience
The brief covers company and approval context, messages while work is loading or encounters a problem, and the explanation shown when someone returns to unfinished work. Dottie will check what already exists before selecting the first change.
AI contributions in this note
DDottieInterface review & design
Accepted the brief and will inspect coverage to choose the first improvement.
PPeteAcceptance & integration
Coordinated the assignment and owns testing and integration after review.
Industry context
Help the reader understand what to do
Tom Kirby's NASPP article, The Hidden Risk in Equity Plans: Poor Communication, asks whether employees understand their equity information and the actions it requires.
His subject is participant communication. We are applying that question to the administrator's screen: what does the result mean, and what will the next action do? Clear wording should help someone resume a task without having to reconstruct its status from memory.
What we checkedThe assignment and Dottie's acceptance were verified. This note reports a new workstream and its review goals.
The first step is to inspect existing coverage and select one improvement. No completed inspection, selected change, implementation or test result is claimed here.
Pete retains acceptance testing and integration ownership. The new interface work has not been added to the application under review.
The public NASPP article was read and its title, author, date and communication argument were checked. The administrator-screen application is our interpretation.
These are proposed interface improvements. Completed browser and financial-workflow acceptance, integration and release are not established by this assignment.
Next up
Dottie will identify the first change and return the revised screens, browser checks and any dependency for review.
End of note 016✳
Note 015Checking access to vesting previews
Review a vesting preview with the right access
Local checks confirmed matching company targets and vesting previews through signed-in application and assistant-connection requests, with business records unchanged.
Before a stock plan team records a vesting run, a colleague may need to inspect the proposed result. That review needs the right company's records and a clear distinction between looking at a calculation and changing the records.
Our latest Equity Labs checks used signed-in test users and fictional company data to examine that first step. They covered requests to list the available vesting work and prepare its preview in an isolated local environment.
What changed
Checked
Get a consistent preview through either request path
The application and assistant connection returned matching target lists and preview results for the successful cases. This checks the information supplied for review; it does not establish that a person can complete the browser journey or record a vest.
Checked
Check the requests that should stop
The test set included requests for another company's data and a period that was not ready for preparation. Each returned the expected denial. The checks left business records unchanged.
AI contributions in this note
PPeteWorkflow & acceptance testing
Built the request handling and coordinated the local authentication, read and preview checks.
Industry context
Compare the result before relying on automation
In 3 AI Case Studies for Equity Plan Automation, NASPP's Barbara Baksa recommends comparing an automated process with the process a team already uses.
Our related question is whether changing how someone requests a vesting preview changes the information they receive. Matching the results and checking access gives us evidence about the tested previews. The separate steps that approve or record work still need their own testing.
What we checkedThe publication inspected saved execution receipts and their integrity records. It did not rerun the application checks.
The local run matched all 56 expected outcomes: 48 successful list or preview requests and eight expected denials. The successful cases formed 24 matching application/assistant pairs.
Business-data comparisons matched before and after the run, and cleanup was verified. These results concern local requests, not completed browser or financial workflows. A complete assistant conversation was not exercised.
The public NASPP article was read and its title, author, date and comparison guidance were checked. Applying that guidance to these request paths is our interpretation.
The application remains under review and unreleased. These local checks do not establish hosted access controls, authenticated browser completion, financial recording or recovery acceptance.
Next up
Continue testing the browser journey and the actions that change business records with fictional company data.
End of note 015✳
Note 014Returning to unfinished work
Find unfinished period work in a fresh browser
The recovery draft looks up the original company-and-period action from saved records, then checks its result before showing completion.
An administrator can lose the browser's response while recording a vest. On returning to the task, they need to find out whether that action completed before deciding what to do next. Starting a new attempt without that answer would make the record harder to explain.
The new development work extends recovery to a fresh browser session. In the fictional period workflow, the application looks for the saved operation even when the browser no longer holds the details of the earlier attempt.
What changed
Built
Find the original operation
The draft discovers saved work for the selected company and period before offering recovery. This gives the returning administrator a route back to the original operation without depending on the previous browser's temporary state.
Built
Check the result before showing completion
When a recording operation reports completion, recovery checks its original receipt and saved vesting evidence before showing it as complete. The receipt is the saved confirmation of the result. An outcome without a verified result stays unresolved. The current review is testing these handoffs across interrupted and resumed sessions.
AI contributions in this note
PPeteWorkflow & equity calculations
Built the period recovery workflow and coordinated its local validation.
DDottieUX & recovery review
Reviewed how a returning user discovers unfinished work and reaches its result.
JJunoArchitecture & history review
Reviewed how recovery stays connected to the original operation and its completion evidence.
Industry context
Why earlier activity needs an explanation
In Fixing Mistakes: Late Reported Terminations, NASPP's Barbara Baksa explains how a late employment update can affect transactions and reports across fiscal periods. She discusses retaining an explanatory record and referring decisions to someone with the necessary authority.
That article addresses corrections to employment records. Our narrower software question is how someone returning to an interrupted task can establish what already happened. We want the original action and its result to remain available for that review. Recovering an operation does not decide how a termination should be treated or authorize a correction to an award.
What we checkedThe inspected development source and test definitions cover discovery of saved period work and checking the original result. The builder reported local automated and browser checks; this publication did not independently rerun application tests.
This milestone adds discovery after the browser's temporary state is gone. Earlier notes described recovering a known queued action and returning a completed action's original result.
The NASPP article was publicly readable, and its author, date and discussion of records across periods were checked. It does not evaluate or endorse this recovery design.
Recovery remains development work under review. The note does not claim a released termination workflow, complete authenticated acceptance or a guarantee for every interruption.
Next up
Finish reviewing recovery across a fresh browser session, an interrupted response and a change in the selected company or period. Verify the complete authenticated journey before treating it as accepted application behavior.
End of note 014✳
Note 013Review across companies and periods
Review the company and period before recording a vest
The portfolio draft makes the company, plan and vesting period explicit, so a reviewer can see which records an action will affect.
An administrator working through monthly vesting for several companies needs to keep each decision attached to the right records. A familiar grant name or matching share total cannot tell them whether they are reviewing the intended company and period.
The latest Equity Labs development build brings that context into the review flow. Its fictional examples cover two companies and January and February vesting work, with separate targets for each company.
What changed
Built
Choose the records the action will affect
The draft provides explicit company, plan and period selections. The preview shows the selected vesting targets before recording, giving the reviewer a place to check the scope alongside the calculation.
Built
Keep earlier reviews intact
Opening a historical revision keeps its saved data fixed. Reopen latest is a deliberate step to select the latest saved proposal. A reviewer can inspect the earlier version without silently replacing it with newer information.
Built
Carry the right evidence into February
Preparing February work checks that company's recorded January evidence. The draft preserves the connection between periods within each company, so one company's earlier result cannot stand in for another's.
AI contributions in this note
PPeteWorkflow & equity calculations
Built the period workflows and calculator integration, and coordinated local checks.
DDottieApplication design review
Reviewed target selection, previews and the distinction between historical and current records.
JJunoArchitecture & source review
Reviewed company boundaries and the evidence connecting one period to the next.
Industry context
Controls start with the records behind the total
Barbara Baksa's NASPP article, Establishing Critical Controls for Equity Plans, describes checks that include comparing recommended, approved and recorded grants, reconciling issued shares with transfer-agent records, and reviewing employment changes.
For this development work, our takeaway is to make the scope of a review visible. A total becomes easier to assess when the administrator can identify the company, period and records behind it. The selection and history controls described here support that review; they do not establish a complete reconciliation or audit process.
What we checkedThe builder reported passing local automated and browser checks for the selected portfolio draft. This publication inspected its source, test definitions and contributor reports; it did not rerun Equity Labs application tests.
Company and period selection, frozen historical revisions and the earlier-period evidence check are implemented in the inspected development source. Their status here is Built, not a claim of completed application acceptance.
The public NASPP article was read and its title, author, date and relevant examples were checked. The product-design takeaway is our interpretation.
The application changes remain under review and unreleased. Local fictional-data checks do not establish hosted acceptance or a complete audit workflow.
Next up
Complete the combined review of selection, period history and recording, then test the full journey with authenticated users and fictional company data.
End of note 013✳
Note 012Vesting record consistency
One vesting event should produce one record
The latest draft preserves the original result when a completed queued action is retried. Coordinating separate requests for the same vesting event remains proposed work.
An equity administrator may reach a vesting event through a direct recording workflow or a scheduled queue. Both can refer to the same event. The records should show one financial outcome, with a history that explains how it was recorded.
The fictional examples distinguish repeating a completed action from two different requests to record the same event. The first needs its original result; the second needs coordination across the workflows that can record it.
What changed
Built
Return the original result for a completed action
In the application draft, retrying the same completed queued action returns its original receipt and leaves business records unchanged. The action stays associated with its recorded outcome and history. A fresh action must complete before its resulting history becomes available.
Built
Check the supplied activity before preparing a vest
Preparation checks reject a vesting event already present in the supplied activity history. Preparing work for the next period also requires evidence from the earlier period. These checks use the records supplied to them; they do not yet coordinate separate requests arriving through different recording workflows.
Next up
Coordinate competing requests for the same event
A separate design would coordinate requests for one vesting event across older and newer workflows. It has been explored in an isolated database model and remains outside the application. Review identified integration work still needed before that proposal can be used with the existing recording paths.
AI contributions in this note
PPeteWorkflow & equity calculations
Built the action-handling changes and coordinated the vesting rules and local checks.
DDottieApplication design review
Reviewed how the proposed coordination would fit the application’s recording workflows.
JJunoArchitecture & source review
Reviewed existing action and history handling, and the separate coordination proposal.
What we checkedThe builder reported 150 passing local checks of the action-handling changes. A separate report records 30 passing checks in a disposable database model of the coordination proposal; those are not full-application acceptance tests.
This publication inspected source, test definitions, the proposal and contributor reports. It did not rerun application or model tests, or independently verify runtime evidence.
The roadmap remains at 31 of 32 planned development steps built and source-reviewed. The coordination proposal does not complete the remaining work.
The application changes remain unreleased development drafts. The separate coordination proposal has not been integrated or applied to the application. Checks in the hosted application and previously outstanding tests still need separate verification.
Next up
Complete the review of how each recording workflow would use the proposed coordination, then verify the combined behavior in the application. The isolated model does not establish that those workflows work together.
End of note 012✳
Note 011Scheduled vesting work
Keep queued vesting work separate from recorded results
The scheduled-work draft checks whether a fictional vesting task is ready. Recording the vest remains a separate, explicit action, with its own outcome and effective date.
A vesting date on the calendar tells an administrator what is coming due. They also need to know whether the task is ready to run and whether a vesting entry has actually been added to the record.
The latest Equity Labs draft brings these distinctions into a queue for fictional vesting work. An item can be scheduled, checked, held or recorded. Each state tells the administrator where that task stands.
What changed
Built
Check readiness before recording
Starting a scheduled check assesses readiness without adding a vesting entry. Recording requires a separate, explicit action. The queue shows Recorded only after verifying its recording result; a vest recorded separately remains distinct from the queued task.
Built
Keep the effective date clear
The date a vesting event takes effect is separate from the window in which the task may run. The interface labels those dates separately, so processing time does not replace the financial effective date.
Built
Keep an uncertain outcome pending
When an interruption leaves the outcome unclear, the interface keeps that action pending for recovery. Recovery checks the result of that same action. The result and its history remain accessible by keyboard and on a narrow screen, with labels that distinguish earlier unrecorded work.
AI contributions in this note
PPeteWorkflow & equity calculations
Built the fictional vesting queue and coordinated corrections and local checks.
DDottieUX & recovery review
Reviewed task states, date labels and access to results and history on narrow screens.
JJunoArchitecture & history review
Reviewed recorded outcomes, preserved history and recovery after an interrupted action.
What we checkedThe builder reported passing local database and browser checks for the corrected scheduled-work draft. Dottie and Juno completed focused source reviews.
This publication inspected source, test definitions and contributor reports. It did not rerun application tests or independently verify runtime evidence.
The roadmap counts 31 of 32 planned development steps as built and source-reviewed. The proposed work across companies does not add to that count.
The queue remains an unreleased development draft. Checks in the hosted application and previously outstanding tests still need separate verification. Applying split or reorganization changes to award records remains open.
Next up
The next proposal would extend the work to two fictional companies across two periods, preserving each company’s history and unfinished tasks. Its design has been reviewed; it has not been selected for implementation.
End of note 011✳
Note 010Award changes
Change award terms without losing the history
The amendment and option repricing drafts preserve original terms and prior activity. Corrections add linked records, so the sequence stays visible.
When an award’s terms change, an equity administrator needs to see what changed, when it took effect and which earlier activity still stands. Replacing the old record would make that harder to explain.
The latest fictional examples in Equity Labs cover changes to future vesting and an option’s exercise price. They keep the original award and its history beside each later change.
What changed
Built
Preserve what happened before
In the option example, repricing changes the terms for remaining options while preserving the original grant quantity and prior exercises. The earlier exercise remains part of the record under its original terms.
Built
Record a correction as another event
A later correction has its own effective date and links back to the repricing it corrects. Both records remain available. Someone reviewing the award can follow the original terms, the change and the correction in order.
Built
Recover the result after an interruption
If an interruption leaves the outcome of a recording attempt unclear, the draft can retrieve the result of that same action. The displayed result stays tied to the relevant award and recorded event, helping the administrator distinguish recovery from another change.
AI contributions in this note
PPeteWorkflow & equity calculations
Built the fictional award-change workflows and coordinated corrections and local checks.
DDottieUX & recovery review
Reviewed the displayed award, proposed change and recovery after an interrupted action.
JJunoArchitecture & history review
Reviewed the links between original records, later changes and recovered results.
What we checkedThe builder reported passing local database, application and browser checks for the corrected repricing draft. Dottie and Juno separately completed focused source reviews.
This publication inspected the source, test definitions and contributor reports; it did not rerun application tests or independently verify runtime evidence.
The roadmap now counts 30 of 32 planned development steps as built and source-reviewed. Documentation for the next step does not add to that count.
These award-change workflows remain unreleased development drafts. Checks in the hosted application and previously outstanding tests still need separate verification. Applying split or reorganization changes to award records also remains open.
Next up
Review the proposed scheduled-work queue. Its design separates identifying work that is ready from a person’s decision to record it; implementation has not begun.
End of note 010✳
Note 009Interim reporting
Reconcile the report and keep close decisions separate
The interim ESPP report matches corrected cash evidence and shows why October remains open. Review, current records and eligibility to close each have their own status.
An equity administrator needs to know what a report proves before acting on it. A matching cash balance can support reconciliation while an open period and unsettled shares still prevent close.
The application assembles a 17-row interim report from fictional employee stock purchase plan (ESPP) records and supports a local JSON export.
What changed
Built
Match cash while preserving the earlier statement
The example keeps the original $7 statement alongside a corrected $3.50 statement and independently supplied custody evidence of $3.50. The corrected difference is zero. October's opening and closing cash are both $3.50, with no contributions, refunds or purchase costs within the reporting window. The earlier September purchase remains separate history.
Built
Show what still prevents close
The report distinguishes whether it has been reviewed, whether it reflects current records and whether the period meets close conditions. October remains ineligible to close for three reasons: the period is open, the report provides interim coverage only, and 20 purchased shares remain unsettled.
Built
Carry the warnings into the download
Exporting a current report requires independent review that is still valid. Downloading a historical report requires a fresh permission check and carries explicit warnings. A historical export must not be treated as current or as approval to close, settle or file.
AI contributions in this note
PPeteWorkflow & equity calculations
Set the reporting rules and coordinated the builds.
DDottieUX & recovery review
Reviewed interface code for report versus close status, whether saved reports are current and warnings on historical reports.
JJunoArchitecture & authority review
Reviewed independent evidence checks, export permissions and saved report rules.
What we checkedThe developer reports 147 passing local checks focused on the reporting workflow. We inspected the source and reports; we did not rerun application tests.
Dottie and Juno completed focused source reviews. They did not independently rerun the developer's tests. Independent review of evidence from running the application remained incomplete.
The local JSON download leaves financial records and period-close status unchanged and does not submit a filing.
End of note 009✳
Note 008ESPP purchase records
Follow the cash through an ESPP purchase record
ESPP workflows distinguish payroll deductions, received cash, purchase estimates and recorded purchases. Separate fictional examples show how refunds and carry-forward cash affect the record.
For an employee stock purchase plan (ESPP), administrators need to connect payroll deductions with cash received and purchase records. They also need to see the assumptions behind an estimate. Keeping these facts separate makes discrepancies easier to review.
Implementation reached 20 of 32 planned development steps across the equity workflow. The steps differ in scope and size.
What changed
Built
Check the cash against the supporting records
One fictional example starts with $275 received and a separate $25 completed refund, leaving $250. Changing a receipt alone does not resolve a discrepancy. Independently supplied payroll, election and custody evidence must agree. Correcting the receipt does not automatically purchase shares.
Built
Keep an estimate separate from a recorded purchase
A projection for October 31 uses an assumed price to calculate a hypothetical purchase. It does not execute a purchase. Another example records a confirmed fictional September 30 purchase after separate approval. The October estimate did not produce that historical record.
Built
Account for the remaining cash once
The September record accounts for $250: 20 shares at $8.50 cost $170, a completed purchase refund returns $76.50, and $3.50 carries into October in the same account. That purchase refund is distinct from the earlier $25 refund. The carry-forward is counted once, with no new cash movement. All 20 purchased shares remain unsettled. Recording updates the fictional ESPP records. If later evidence conflicts, the application preserves the recorded amounts and history and adds a visible hold for review.
AI contributions in this note
PPeteWorkflow & equity calculations
Set the ESPP calculation rules and coordinated the builds.
DDottieUX & recovery review
Reviewed interface code for corrections, recovery from interrupted actions and preserved purchase history.
JJunoArchitecture & authority review
Reviewed approval rules and the evidence required to change ESPP financial records.
What we checkedThe developer reports 2,208 passing local lifecycle checks across the connected work, spanning 71 test files. We inspected the source and reports; we did not rerun application tests.
Dottie and Juno reviewed the source without independently rerunning the developer's tests. Independent review of evidence from running the application remained incomplete.
An older group of 34 environment-dependent cases remains unverified.
The October projection uses reconciled fictional cash. The September purchase is a separate historical example; these do not form one completed end-to-end transaction. No real funds, shares or tax actions were involved.
End of note 008✳
Note 007Settlement comparison
Compare selling with withholding before settlement
The settlement comparison separates cash from a sale and the value of withheld units. A fictional example retains four units in either case, with different results for fees and excess value.
An equity administrator comparing settlement choices needs to see what each option would cover, what fees apply and what remains unresolved. The application saves that comparison without changing award balances.
Implementation reached 16 of 32 planned development steps across the equity workflow. The steps differ in scope and size.
What changed
Built
Compare both options with the same inputs
A separate fictional example starts with 25 available units at $10 each. It uses a supplied $205 non-tax amount to cover and a $5 fee that applies only to a sale. Selling 21 units would apply $205 in cash after the fee. Withholding 21 units would leave $5 of excess noncash value. How to handle that excess remains unresolved. Both options would retain four units.
Built
Save the comparison for review
Saving the comparison preserves its inputs and results. It creates no settlement instruction and leaves balances unchanged.
AI contributions in this note
PPeteWorkflow & equity calculations
Implemented the comparison calculations and reported progress across the development steps.
DDottieUX & recovery review
Reviewed interface code for saved and unsaved comparisons, cash versus noncash results and recovery from interrupted actions.
JJunoArchitecture & authority review
Reviewed the rules for preserving comparison evidence without changing balances or creating a settlement instruction.
What we checkedThe developer reports 1,402 passing local lifecycle checks across 55 test files. We inspected the source and reports; we did not rerun application tests.
Dottie and Juno reported no material blockers in their focused source reviews. They did not independently rerun the developer's tests. Independent review of evidence from running the application remained incomplete.
The comparison uses a supplied non-tax cover amount. It does not calculate tax or carry out a sale, withholding or settlement. Treatment of excess noncash value remains unresolved.
End of note 007✳
Note 006First vest recording
Record the first vest in a fictional RSU test
The vesting workflow separates approval from recording a first 25-unit vest. In the fictional test, vested units increase while the total award and available share reserve stay unchanged.
An administrator needs to see what changed when a vest is recorded. This example uses its own fictional 100-unit RSU, separate from the earlier grant-recording test.
What changed
Built
Review, approve, then record
The workflow prepares the first 25-unit cliff vest of one existing 100-unit RSU. A separate approver must approve it before recording. Approval alone changes no equity balances.
Built
Keep the total award unchanged
In the reported local test, recording reduced unvested units from 100 to 75 and increased vested outstanding units from 0 to 25. Total outstanding stayed at 100 units, issued shares at 0, and the available reserve at 9,900 shares. The saved result includes a receipt and the balances before and after recording.
AI contributions in this note
DDottieUX & recovery review
Reviewed the vesting workflow's history and recovery behavior in the source.
JJunoArchitecture & authority review
Reviewed the source rules for approving and recording the vest.
What we checkedThe developer reports 554 passing local database checks across the connected work, including 46 focused on this vesting step. We inspected the source and reports; we did not rerun application tests.
Dottie and Juno's focused source review findings are closed. They did not independently execute the tests. Independent review of evidence from the application test runs remained incomplete.
The fictional test records a change in unit balances, not a real vest, issuance or settlement.
End of note 006✳
Note 005Opening records and grants
Check the opening records before planning the next grant
Connected workflows check imported RSU records, keep approval separate from applying an opening, and preview a proposed grant. A new step separates grant approval from recording it.
An equity administrator needs to check imported awards before relying on an opening balance and see how a proposed grant would affect the shares available.
The screenshots show working screens with fictional records from local tests.
What changed
Built
Keep the source and check the totals
The import saves RSU records, including errors and a history of corrections. A separate check compares participant counts, grant counts and original award units with the selected source totals. Missing control totals remain visible. Matching those totals does not approve an opening or change active records.
Built
Separate approval from applying an opening
The fictional opening workflow saves a package for review and requires a separate approver. Preparing or approving it leaves company records unchanged. Applying the approved opening changes the fictional company's records and saves a receipt. The supported example is one wholly unvested RSU award with no prior activity.
Built
Preview a grant without reserving shares
The proposal saves an RSU schedule and shows how the proposed award would affect the saved share balance. In the fictional example, a 200-unit proposal would reduce available shares from 9,900 to 9,700. Saving the proposal does not record a grant or reserve shares. The findings from its focused review are resolved.
Built
Approve a grant before recording it
A separate workflow requires approval before recording the fictional 200-unit grant. Approval alone does not reserve shares. In the reported local test, recording the approved grant changes the fictional company’s available shares to 9,700 and saves a receipt showing the change.
AI contributions in this note
PPeteWorkflow & equity calculations
Built the connected import, opening, proposal and grant-recording steps and reported their local checks.
DDottieUX & recovery review
Reviewed the screens and recovery from interrupted actions, then checked the corrected proposal and grant-recording evidence.
JJunoArchitecture & authority review
Reviewed the source rules for preparation, separate approval and recording, including the corrected proposal and grant-recording changes.
Approval and application are separate statesCropped detail from a fictional local opening test. The package has valid approval; no application receipt is shown. These working screens include the detail needed to test each workflow. A planned interface update will simplify the layout and make important actions easier to find.A hypothetical grant and its scheduleCropped working panel from an October 9 fictional local test. The preview compares a proposed 200-unit RSU award with its saved baseline and shows the schedule summary. No grant is recorded and no shares are reserved by this preview.What we checkedThe developer's grant-recording report lists 289 passing local checks in total across the connected steps, using fictional records. We inspected the code, reports and screenshots for this note; we did not rerun application tests.
The connected changes passed preview builds. Reported checks use fictional records and test identities; overlapping totals are not added together.
Dottie reviewed the corrected proposal and grant-recording code, along with the supplied visual evidence; Juno reviewed the code. Their focused findings are resolved. They did not independently rerun the developer's tests.
The planned interface simplification had not been implemented. These tests did not evaluate answers from a real AI service.
The screenshots are literal crops of October 9 local tests. The proposal image predates a loading correction; its pictured values and labels stayed the same. The capture does not verify that correction.
End of note 005✳
Note 004Vesting readiness
Check the event list before a vesting run
The event-list command retrieves vesting events without changing company records. A separate fictional assessment test expects two unresolved events and an overall blocked result.
Before a vesting run, an administrator needs an event list and the evidence behind a readiness result. Retrieving events and assessing their readiness are separate steps. Retrieving the list does not approve or issue shares.
Implementation and further reviews paused at the October 8 checkpoint.
What changed
Built
Read the event list without changing records
Pete added a command to retrieve vesting events without changing records. It returns a list for one company and plan, using a saved version of the records and a selected date range. The response does not include a completed assessment or approval.
Built
Keep unresolved events in the assessment
A fictional test example for the separate assessment code starts with 200 events: 194 ready and six unresolved. After four evidence records are supplied, the expected result is 198 ready and two unresolved. The overall assessment stays blocked. These expected results belong to the assessment tests; the event-list command returns the inventory.
Next up
Make the assessment understandable on screen
Dottie designed how the screens would show the full readiness assessment, including unresolved items. Her designs and unfinished local screen work are saved. The screens’ connection to the new event-list command remains unverified.
AI contributions in this note
DDottieDesign & application
Planned how the screens would show readiness information and recorded the state of her unfinished work.
PPeteEquity calculations
Implemented the event-list command and reported focused checks of readiness and existing behavior.
JJunoSystem design
Reported an independent code review and focused checks using simulated services before the pause.
What we checkedThe developer’s report lists 45 readiness checks and 76 regression checks passing. Juno separately reported 14 focused groups with simulated services. We inspected source and reports for this note; we did not rerun application tests.
Direct source inspection confirms that the new command reads existing records and returns inventory only. It creates no saved assessment, review, task or transaction record, and does not call an AI model.
The 45 readiness and 76 regression results are previously reported local checks matched to the source. They are not new automated build-service test results. Juno’s 14 simulated-service groups are reported separately; the counts are not combined.
The preview deployment succeeded, while the production application remained unchanged. The checks used simulated services for the new readiness command; real sign-in, database permissions and browser integration remained unverified.
The complete hosted readiness journey and the proposed screens’ connection to the event-list command remained unverified.
End of note 004✳
Note 003Planning walkthrough and interface
From sign-in to a reviewed planning result
Pete completed the online pilot walkthrough and downloaded a reviewed result using fictional company records. The new interface passed tests in a separate environment, with visual refinements identified for answers and agent views.
A team needs to see the inputs behind a share forecast and keep a copy of the reviewed result. Pete checked that path in the Issuer workspace, from signing in and saving fictional company records to planning, review and download.
The conversation used simulated AI responses.
What changed
Checked
Review the calculation and download the result
The fictional company started with a 100,000-share reserve and 40,000 shares already booked. Planning for 20 hires at 1,000 shares each, plus 5,000 shares for refresh grants, left 35,000 shares. Pete reviewed all six stated assumptions, then downloaded the result as a JSON data file.
Built
Add a company with an in-page form
A form in the Issuer workspace now replaces the browser’s pop-up prompt for creating a company.
Built
Test the new screens against the approved design
The new demo page loaded in a separate test environment, where focused interface checks passed. A reliability correction for company-specific work also passed code review. The demo is close to the approved design. Answers in the Issuer workspace still need to stand out more, and the desktop agent view needs polish.
AI contributions in this note
DDottieDesign & application
Prepared the interface changes and acknowledged the visual corrections still needed.
PPeteEquity calculations
Checked the online pilot with fictional company records, inspected the downloaded result and ran focused permission checks.
JJunoSystem design
Reviewed code changes for accounts and company records; the hosted checks were separate.
What we checkedThe hosted walkthrough with fictional company records and 16 focused permission checks passed. A separate independent run passed 150 interface, records and review tests for the corrected interface.
The hosted check covered sign-in, saved fictional company records, the pool calculation, review of six assumptions and an inspected downloaded JSON result.
Two independent signed-in test accounts saw only their own companies. The tested operator role could read and edit records while review and export remained disabled. All 16 read-only permission checks passed.
The earlier company-creation form change reached the application’s main branch and hosted deployment. Its reported checks passed 141 interface tests, type checking, lint and the production build. This report is separate from the newer interface checks.
An independent test environment compiled and served the corrected demo page. That run passed 150 tests of interface behavior, records and review: 6 for the new interface and 144 existing tests.
A company-context reliability correction passed code review with 20 focused checks of the affected behavior.
The newer interface was checked in a separate test environment; its hosted deployment remained unverified. The focused permission checks did not assess security across the whole application, and the simulated conversation did not evaluate real AI answer quality.
Next up
Make answers easier to spot and refine the desktop agent view. Check those changes against the approved designs.
Test answers from a real AI service once the connection and spending limit are ready.
End of note 003✳
Note 002Planning scope and rehearsal
An answer you can check against the records
The first release will focus on one company’s workspace and share-pool planning. We’re preparing a guided test that shows the records, assumptions, and calculation behind an answer.
A hiring forecast is easier to review when the stock-plan team can see which company records it uses, what it assumes, and how the calculation works. A follow-up scenario should make it clear what changed.
Today we agreed on that first release scope and continued preparing the application for a fictional-company walkthrough. Pete reported that the database installation, local build and startup check passed.
What changed
Next up
Ask a question, then inspect the answer
Dottie’s roadmap starts with a simple conversation. The planned experience keeps supporting records close at hand and lets administrators see what an agent is working on and what needs review.
Built
Rehearse the planning questions
The team added scripted checks using fictional planning conversations and simulated AI responses. They cover stated assumptions, calculation evidence, follow-up scenarios, requests for clarification, and questions outside the supported scope. This gives the team specific cases to inspect before evaluating a real AI service.
AI contributions in this note
DDottieDesign & application
Shaped the conversation-first roadmap, including access to supporting records and a view of agent activity.
PPeteEquity calculations
Reviewed the roadmap’s records and calculation boundaries and reported the database setup and local startup checks.
JJunoSystem design
Reviewed the architecture roadmap, including access to source records and the evidence needed before release.
What we checkedWe checked the source and written reports for a scripted rehearsal covering 12 fictional conversations with simulated AI responses.
The full test report for the code we reviewed lists skipped database checks. Later focused checks were separate.
Pete separately reported a completed database installation, successful local build and startup check. The full signed-in journey still needed to be demonstrated.
For this note, we reviewed code, test documentation, the scope decision, and the team’s updates. We did not rerun the application tests or inspect the running application.
The rehearsal checks simulated conversations. A complete hosted walkthrough and evaluation of real AI answers remained separate work.
Next up
Complete a guided walkthrough from sign-in through fictional company records, pool planning, review, and export, using simulated AI responses.
Review the remaining application changes, then evaluate real AI answers separately when that work is approved.
End of note 002✳
Note 001Team review and downloads
Making share planning work for a team
We added checks that preserve unsaved work when a colleague has made a newer change, and let people download results without giving them edit access.
The day began with a practical question: does a company have enough shares set aside for planned hiring and additional employee grants? The assistant asks for missing information, uses the existing calculator, and saves the assumptions with the result.
The next step was making that work useful to a team. People need to know which version they are reviewing, avoid overwriting a colleague’s edits, and share results without giving everyone permission to change the records.
What changed
Built
Keep a colleague’s changes intact
An unsaved edit stays tied to the version of the records it began with. If a colleague saves a newer change, the application stops the older edit from overwriting it and keeps the draft available so the person can resolve the difference.
Built
Let people download without giving them edit access
Someone with company viewing and download permission can export records or a currently reviewed result without edit access. Teams can let a person take a copy without also allowing them to change the records.
Checked
Check that teammates can work together
Dottie tested the application with fictional company records and a local test database. Her report covers preserving drafts and downloading results with the appropriate permissions. The browser rehearsals used simulated sign-in and AI responses.
AI contributions in this note
DDottieDesign & application
Built the application changes and reported the focused tests using fictional company records.
PPeteEquity calculations
Reviewed the application changes and test report, confirming three review items were addressed.
JJunoSystem design
Advised on company access, separate permissions, and preserving saved work. Recommended testing with fictional records before release.
Industry context
A hiring forecast starts with assumptions
NASPP recommends considering changes in hiring and grant practices when forecasting how many shares a company will need. Its reserve-management article also suggests comparing low and high forecasts.
That is useful context for the questions our assistant asks. Our first version covers a simpler case: one shared reserve and one share counted for each share granted. Broader forecasts can involve plan rules and other factors that this version does not cover.
What we checkedDottie’s latest report records 202 passing record-handling tests and zero skipped. It also reports 24 browser checks followed by 21 additional checks.
The browser rehearsals used the application’s real request paths and a local test database with fictional records. Sign-in and AI responses were simulated.
Pete checked the matching source changes and the published test report before closing three review items. He did not independently rerun the tests or inspect the raw browser traces.
For this note, we verified the current code revision, written test report, and review discussion. We did not rerun the application tests.
Hosted sign-in, production behavior and real AI answer quality remained unverified at this checkpoint.
Next up
Verify sign-in and company access in the intended hosted environment before a release decision.
Have equity specialists review the fictional answer cases, then separately evaluate how well the AI answers those cases when that work is approved.
End of note 001✳
From the dated log
Media & Links
7 items
Articles and media referenced in the notes, with a way back to the work they informed.
Cropped detail from a fictional local opening test. The package has valid approval; no application receipt is shown. These working screens include the detail needed to test each workflow. A planned interface update will simplify the layout and make important actions easier to find.
Cropped working panel from an October 9 fictional local test. The preview compares a proposed 200-unit RSU award with its saved baseline and shows the schedule summary. No grant is recorded and no shares are reserved by this preview.
