Decisions and evidence

Decision registerLink

Use one record per decision: ID, question, current proposal, status, owner, supporting evidence, decision date, effective date, review date and affected wiki pages. Status options are Proposed, Adopted, Revised and Retired. Vimal is the initial owner and approver. No adoption dates are recorded in this version.

Priority decisions: positioning and exclusions; direct versus specialist capabilities; working hours and market; agency relationship rules; usable proof; real financial inputs; price anchors and allocations; payment and defect terms; public site tools and copy; outreach eligibility and messages; spend limits and review cadence.

Source registerLink

P — Nusigma_Business_Positioning_V1.docx: identity, profiles, pillars, boundaries, claims and validation.

C — Nusigma_Commercial_Model_V1.docx: offers, price hypotheses, capacity, economics, cash and commercial controls.

W — Nusigma_Website_Strategy_V1.docx: public pages, copy, contact, technical approach and launch.

L — Nusigma_Lead_Generation_Strategy_V1.docx: targeting, channels, messages, pipeline and 90-day learning.

All four live in Business Docs and are dated 11 November 2026, review version 1. Source references on wiki pages use these keys and numbered source sections, not rendered page numbers.

Proposed wiki maintenanceLink

Each page has an ID, path, purpose, source, owner, status and review trigger. Keep each rule in one canonical page and link to it elsewhere. Update a rule’s source and decision record when it changes; preserve old source files and mark superseded decisions. Record change date, reason and affected pages.

Weekly: update work, pipeline, capacity and cash records. Monthly: review economics, claims, assumptions and open decisions. At day 90 and after material changes: review the overall model. These governance mechanics extend the source strategies for the private wiki.

Privacy and operational recordsLink

Require authenticated private access when the wiki is built; exclusion from search alone is insufficient. Give access only to authorized users, back up the wiki and verify recovery. Reference secure credential storage rather than copying secrets. Keep client-sensitive records permissioned and link only approved material into public pages.

Initialize registers for decisions, capability/proof, opportunities, engagements, cash and dependencies. Use the schemas in Specialists and responsibility, Acquisition routine, Pipeline and discovery and Proof and voice. Leave unknown values explicitly unconfirmed rather than filling them with examples. Store actuals separately from planning scenarios.