Recent thoughts

Provisional weekly perspective review, 2 Nov 2026 (not user-endorsed conclusions): Five possible blind spots to test: (1) O9X may save software cost without proving improved guard-site economics, billing cycle or ROCE; evaluate measurable business outcomes, especially given 29 Oct ADT/Thrive deal (US residential monitoring, not directly comparable to Indian static guarding). (2) Founder's strategic involvement differs from founder-only incident response: test whether staff can detect/recover O9X failures and invoke existing payroll fallback without him, given 29 Oct Cursor marketplace supply-chain attack. (3) Before adopting Google Elephant-Goldfish/WikiSkill orchestration, compare accepted tickets, review time, failures and tokens against existing workflow; skills research finds many add no benefit. (4) Murakami-inspired personal prose should be learned through observation, selection and scene details, not merely copied stylistic markers or AI style-matching. (5) 16-week sub-2h half-marathon plan should account for Delhi's poor AQI (Nov 1), treadmill/road transfer, strength training and Nov 14-25 travel. These are questions for exploration, not settled decisions.

24 Oct 2026 essay project: primary audience is BUSINESS OWNERS like Kiran, NOT fresh graduates. Goal is to show how small-business owners' operating and hiring decisions are changing because AI makes bespoke automation quick and affordable. Secondary audience graduates, who can infer how employers think and adapt before being surprised. Trigger: IISc/NPTEL professor asks why students come to class when LLMs can teach, fears loss of campus jobs. Kiran's concrete pre-AI evidence: move from Tally/Excel to Zoho Books and custom payroll aimed first at reducing dependence on one accountant; company grew about 80% without hiring ~2 additional office staff he thinks otherwise needed. Original accountant left after stroke (NOT laid off); replacement with ~2 years experience could handle documented software-based system. AI adds a new layer: makes tools cheaper/faster to build and customize without vendors or growth threshold; O9X operations already replaced WhatsApp, payroll in advanced testing (95% self-estimate, target end-2026, not yet live). Team tests daily, owner fixes edge cases in hours vs 3-4 days vendor turnaround. Goal is to standardize 80% baseline performance, capture improvements from top employees; currently sole builder in V0, plans V1 + train 1-2 maintainers. Businesses may see more revenue and total field jobs but fewer incremental office hires per revenue, especially fewer fresher support roles; this is about forgone opportunities, not necessarily firing staff. Illustrative only: 3X revenue with 7 office employees vs maybe 10 with ordinary scale efficiencies, NOT 15 linear extrapolation. Business wins may come from new demand or diverted business; net national employment unknown, including software-vendor effect. Software lowered qualifications for some jobs, so opposite effects exist. Graduate is secondary audience: understand how owners' hiring priorities are changing (AI capability + business judgment might matter more than degree alone). Avoid sensational employment predictions and unverified national office staffing %.

Psycho-Cybernetics audit (2026-10-08): KB chose not to read the book to avoid absorbing false beliefs. Claude audited a Claude Code essay on it. Material errors found: a misattributed "2024 meta-analysis of 27 studies" (real source: Jiménez Díaz 2022, 24 studies), an unverified Selye quote, an outdated habituation model of exposure, overstated arousal reappraisal (real effect d≈0.23), and longevity claims built on cohort data (Generation 100 RCT showed no overall mortality difference). Lesson: sub-agent research produces plausible but unverified citations; spot-check every named study. Output: a 10-week evidence-only plan (one target, 2-week baseline, mastery reps, rehearsal with obstacles, reviews at week 6 and 10).

Understanding AI project architecture update (7 Oct 2026): Core sequence is now 1) What is AI? 2) How does modern AI do what it does? (includes why AI improved so much as a sub-theme) 3) What can AI actually do? 4) Why does AI behave the way it does? 5) When does AI expand my thinking, and when does it replace it? 6) Can I trust AI? 7) What changes when a model becomes a system? 8) What changes inside organisations when AI becomes part of work? 9) What does AI cost, and who captures the value? 10) What changes at the level of an economy or country? 11) Where does this leave me? Optional: profession-specific use cases, access to knowledge vs expertise, technology leap vs investment bubble, small-business capability, AI as intermediary for knowledge/authority, how I currently work with AI, interpretability, consciousness, security/privacy/data rights, accountability, possible chronological history. Explicitly out of scope: government policy prescriptions and geopolitics. Next step in a fresh session: source mapping using the older handoff, a newer handoff, and both research reports.

Understanding AI project — trust model from O9X (7 Oct 2026). Kiran does not trust an AI model directly; he builds layered verification around it. Workflow: define work; write tests before coding so tests encode intended behavior rather than conforming to generated code; use separate stateless agents/skills for independent review loops; use Playwright for UI verification; manually verify claimed outcomes and logic; then let staff expose production edge cases. Verification depth changes with legal/financial consequence. Even if first-pass accuracy reached ~99%, he would keep tests and verification because he wants a deterministic system around a probabilistic component and because he cannot inspect code deeply. His broader principle is system-first accountability: do not blame the person/AI for failure; blame and improve the system that allowed the failure.

Understanding AI project — candidate core tensions from Kiran: (1) AI can outperform him on bounded tasks yet becomes unreliable on complex, open-ended work without guidance; (2) AI provides instant answers but may not create real expertise or understanding of why/how; (3) AI will automate some tasks and create new ones, so the practical question is what to automate versus what new work to learn; (4) AI may be a genuine technological leap while the capital cycle around it could still be a financial bubble, and timing bubbles is unreliable; (5) AI gives small business owners access to capabilities once unaffordable, but extracting that value still requires substantial thinking and planning; (6) AI can expand human thinking but can also become a substitute for core thinking.

Understanding AI project — clarified stakes (7 Oct 2026). Kiran wants 'What can AI do?' to teach readers how to evaluate claims rather than freeze current capabilities: distinguish marketing from real-world usefulness, question benchmarks, and examine incentives of both buyers and AI developers. 'How does AI do what it does?' should give a business owner a technical but accessible account of how current LLMs process input and produce output. 'What changes due to AI?' contains three contrasting adoption contexts: software developers who embraced AI; professionals inside large firms with mature deterministic systems who are told to adopt AI but struggle to see the job-to-be-done; and business owners like Kiran who can now build capabilities they previously could not afford. 'Where does this leave me?' is explicitly personal: his own learnings and changed judgement after writing the series.

Understanding AI project — Kiran's 2x2 from experience: clear goal + short context ≈ 90% success; clear goal + long context still works very well but sometimes mixes 2-3 ideas and needs reminders; vague goal + short context is decent and can become clearer through interaction; vague goal + long context fails every time. This creates a useful tension with the simple claim that context length alone causes failure: in Kiran's own experience, long context is tolerable when the goal is clear, while ambiguity and long context together are disastrous.

Understanding AI project — Kiran's experience buckets. Great: (1) AI performs very well when the desired output is tightly defined and supported by a specific skill/instruction set; (2) model statelessness lets him ask the system to re-read the whole conversation and critique prior output, often finding real flaws; (3) AI is strong for exploratory learning because it reduces search/friction, can consolidate material into long-form prose, and supports follow-up questioning. Okay: writing output is structurally competent but repetitive/artificial and lacks the punch of strong human prose; AI is more useful as a reviewer. Planning without constraints looks plausible but lacks real-world detail; planning improves after discussion of constraints and exclusions. Poor: one-shot coding launches more often now but still contains many flaws, so he plans deeply before implementation; hallucinations plus confident tone require web/source validation; the assistant's trained helpfulness can become excessive and pleasing rather than truth-seeking.

Understanding AI project insight (6 Oct 2026): Kiran's aim is not just to explain AI but to test whether conclusions drawn from 3-4 years of heavy AI use generalize beyond his own experience. His current hypotheses: AI works best on tightly scoped tasks with explicit goals and non-goals; model switching costs for coding are low because workflows have standardized; model quality changes quickly so attachment to one provider is fragile; vocabulary and concepts materially affect output because the framing steers model behavior; and giving AI broad autonomy has produced worse results than keeping the human responsible for the work. The essay series should pressure-test these experience-derived beliefs rather than assume them.

2026-10-06 — Built retrieval-coach skill v1 (strict retrieval practice, Google Doc ledger per learning project, never gives the answer). Build decisions: cue ladder cut to three steps (gap type → one narrowing cue → reread) to match "three failures then reread"; Source Map placed last in the ledger under an ANSWER KEY warning because the learner can open the Doc; if the original source is unavailable, a third failure is marked FRAGILE ("reread pending"), not UNDERSTANDING BLOCKED, since forgetting can't be told from not understanding without a reread; selection gate nominates ideas by name only so first free recall isn't contaminated. Open risk: tests were self-simulated by the builder, not run independently; first real session is the true test.

2026-10-06 | Open-source/product boundary lesson from Horilla and local-app exploration. When building proprietary value around an LGPL or otherwise copyleft base, do not assume secrecy in modifications is the moat. Keep the legal boundary clean: preserve the upstream licence rights and place proprietary differentiation in separate APIs/services, integrations, operational know-how, brand and support where possible. More broadly, for desktop/local products prefer the smallest deployable architecture that serves the use case rather than bundling an entire server stack: reuse a native shell/client and local sidecars where practical, and omit infrastructure such as search, queues or workers until the product actually needs them.

2026-10-06 | Learning method refinement. For long thematic material, Kiran's active-recall loop is: read one theme, close the text, recall from memory, reopen and check gaps; after a small cluster (for example three themes), recall the cluster cumulatively rather than only the latest section. For much longer documents, cumulative retrieval should expand in intervals instead of trying to reproduce the entire document after every section. The larger principle matches his AI rule: attempt unaided retrieval first, then use the source or AI as feedback, so external support strengthens the memory trace instead of replacing recall.

2026-10-06 | Writing and AI boundary. Writing serves two different functions for Kiran: private writing is part of thinking and should preserve the struggle needed to form judgment; public writing is craft and may use stronger editorial assistance. A useful rule is retrieval or first judgment before AI, then use AI for research, critique, option generation, editing or drafting without outsourcing the accountable judgment-forming step. Linters are most useful as negative constraints that catch recurring defects; turning admired positive traits into hard rules risks freezing voice. Transcript-to-prose and other source-derived writing also need an explicit authorship/publishability boundary so preservation, transformation and original contribution are not confused.

2026-10-06 | AI-assisted engineering operating rule. Kiran wants AI to expand implementation capacity without becoming the authority. Canonical workflow: grill-with-docs -> to-spec -> Goldilocks review -> to-tickets -> implement -> code review, with TDD/vertical slices, explicit assumptions, no guessing ambiguous business rules, no silent catches, no bypassing checks, and unfinished work made visible. Cheaper/faster models can be implementation workers or bounded routing/classification layers, but architecture, compliance and acceptance need deterministic gates and independent review. Model changes should be benchmarked on the same closed O9X tasks, using accepted-ticket cost, human attention, review rework and escaped defects, and model/version aliases should be pinned or validated before upgrades.

2026-10-06 | O9X associate-attendance V1 architecture. Desired user flow remains intentionally simple: mobile number plus last four Aadhaar digits for initial login, selfie match against stored picture, one-device binding, and server-side GPS/geofence check-in on ordinary Android/iPhone browsers. Architectural direction: keep this as a separate lightweight Cloudflare attendance/identity service so the main ERP stays simpler; Supabase remains the master employee source, minimal associate data syncs to the service, existing R2 photos are reused, and attendance flows back to O9X through an API. Face matching is 1:1 verification, not broad identification; liveness is a separate control; embeddings are model-specific/versioned data. Further refinement: Aadhaar-derived data is a weak routine authenticator and should be treated mainly as onboarding/recovery context, while ongoing trust should come from possession/device binding, biometric verification and location.

2026-10-06 | Changed position on slow-paying clients and wages. On 17 Sep Kiran was still considering contract language that would hold employee salaries until client payment cleared. Later analysis produced a stronger principle: employees should not finance a customer's working-capital delay through withheld earned wages. Slow-paying-client risk should be handled through client selection, credit limits, reserves, suspension/termination rights, pricing and other business-level controls rather than shifting the financing burden to workers. Treat this as an evolution from the 17 Sep unresolved position, not as if it had always been settled.

2026-10-06 | O9X data/compliance architecture principle. Establish one canonical operational record in the form closest to how work is actually observed, then derive payroll, compliance, customer and management views downstream. When an error is found, correct the source record so every representation changes together. Statutory logic should be modelled as effective-dated/versioned rules rather than scattered conditions: separate the legal basis, employee state, wage definitions, eligibility and calculation. Consequential payroll/compliance decisions should remain deterministic and auditable even when AI is used around them.

2026-10-06 | O9X strategic thesis sharpened. The main automation target is not the guards doing physical work; it is the coordination labour around them: recruitment, deployment, attendance, rostering, payroll exceptions, compliance, billing, incidents and MIS. The proof metric should be internal operating leverage at Knighthood, such as guards supported per supervisor/office employee while service quality holds. O9X should first improve Knighthood's economics before being treated as a SaaS product. The customer proposition should move from "we supply guards" or "we have software" toward a verified operational outcome: correctly deployed, legally rostered, attendance-verified positions with live evidence. AI savings do not create value if clients simply force service fees down; reliability and evidence must be made visible enough that Knighthood captures part of the efficiency gain.

2026-10-06 | Important tension in Kiran's decision style: systems, reference classes, bounded bets, downside protection and preserving options are real strengths, but they can become a way to postpone commitment. The failure mode is not caution itself; it is allowing optionality to become the default objective after evidence is already sufficient. Exploration then creates attention cost, delays learning from full commitment, divides resources and sacrifices compounding. Practical warning sign: Kiran reaches the commitment threshold he previously set, then invents another threshold. Future decisions should distinguish genuinely missing evidence from discomfort with closing doors, and define in advance how "keep learning" converts into kill, continue-small, or commit-and-scale.