Programme Visibility Standard
What a programme organisation can see about founders participating through it, what stays private, and why programme access does not mean founder access.
1. Why This Standard Exists
Programme Delivery requires organisations to administer participation, understand progress and evaluate outcomes.
It does not require unrestricted access to the founder's private operating environment.
The governing principle is:
Programme participation does not transfer ownership or general visibility of a founder's private operating environment to the programme organisation.
The locked programme boundary: individual programme progress metadata may be visible by default to the relevant programme organisation where reasonably required to administer and operate the programme, and clearly disclosed to the founder when they join. Substantive Founder Content, Founder Memory and Founder Intelligence conversations remain private by default unless the founder deliberately shares or submits defined information, or another specifically disclosed and separately governed programme requirement applies.
This Standard applies to all founders, not only founders aged 16 and 17.
2. The Zero→1 Trust Architecture
This Standard completes a set of four connected company-wide principles:
- Private by Default.
- Founder Intelligence recommends. Founders decide.
- Founder Memory is a curated operating state.
- Programme access does not mean Founder access.
These are mutually reinforcing. A founder can use Founder Intelligence candidly, allow Zero→1 to build useful contextual memory and participate in an institution-funded programme without having to assume that the institution is watching their private work.
The first three principles are set out in our Founder Intelligence Agency Standard and Founder Memory Governance Standard.
3. The Standard
Programme access does not mean Founder access.
A programme organisation's relationship with Zero→1 gives it access only to founder information reasonably required to administer, operate and evaluate the agreed programme.
Founder Content, Founder Memory and Founder Intelligence conversations remain private by default.
Programme administration and progress information must be separated from substantive founder work.
Where Founder Content is shared with a programme organisation, sharing must be specific, purposeful and transparent. The founder must be able to understand what is being shared, with whom and why.
Programme sponsorship, funding or purchase of access does not itself create unrestricted access to a founder's private operating environment.
4. The Five-Layer Visibility Model
All Programme Delivery functionality fits information into one of five visibility layers:
- 1. Private Founder Workspace: Founder Content, Founder Memory, Founder Intelligence conversations and private work. Programme visibility: no.
- 2. Programme Administration: information necessary to administer programme participation. Programme visibility: yes, where necessary.
- 3. Progress & Participation: defined programme progress metadata. Programme visibility: yes, where defined and disclosed.
- 4. Shared / Submitted Founder Outputs: specific substantive work deliberately shared or submitted. Programme visibility: only through defined sharing or submission.
- 5. Programme Outcomes: programme evaluation and outcome reporting. Defined and minimised, aggregated where appropriate.
These layers exist as substantive permission boundaries, not merely labels in policy documents.
5. Layer 1: The Private Founder Workspace
The following remain private from programme organisations by default:
- Founder Intelligence conversations;
- Founder Memory;
- AI-generated inferences about the founder;
- draft Mission responses;
- private notes and reflections;
- unsubmitted evidence;
- raw customer research;
- private business ideas;
- uploaded documents, images, audio and video;
- working and draft business plans;
- commercial assumptions;
- financial information not specifically shared;
- private commitments;
- psychological or behavioural inference; and
- sensitive personal information.
The fact that an organisation purchased access, sponsored access, invited the founder, operates the programme, funds the programme or employs programme personnel does not itself alter this default.
Programme sponsorship does not create data entitlement to the founder's private workspace.
6. Founder Intelligence Conversations Stay Private
Programme organisations do not automatically receive transcripts, conversation summaries, prompts, AI responses, inferred concerns, AI assessments, conversation sentiment, topics discussed or derived behavioural conclusions.
A programme dashboard does not provide an administrator with a general facility to inspect Founder Intelligence conversations.
7. Founder Memory Stays Private
Founder Memory is explicitly excluded from ordinary programme visibility: no memory records, memory summaries, AI-derived operating profiles, inferred founder characteristics, internal uncertainty states, evidence-confidence judgements or private decision histories.
Founder Memory is private operating context, not programme reporting data.
8. Layer 2: Programme Administration
Programme organisations may receive information reasonably required to administer participation: founder name, relevant contact information, programme membership, invitation and activation status, programme or cohort, access status and dates, licence status and other genuinely necessary administration information.
Administration data is not expanded merely because additional information is technically available.
Administrative necessity, not technical availability, determines administrative visibility.
9. Layer 3: Progress and Participation
Individual programme progress metadata may be visible by default where reasonably necessary to operate the programme and disclosed to the founder when they join: programme started, Journey started, Stage reached, Missions started and completed, required activity completed, programme completion, last activity date, objectively calculated progress percentage and defined milestones.
This is metadata about participation, not permission to inspect the underlying founder work.
"Mission 6 completed" may be visible. That does not mean "show the programme administrator the founder's Mission 6 answers".
Every programme-visible progress field has a documented meaning. There is no open-ended "programme data" category.
10. Activity Is Not Psychology
Programme progress reporting uses objective participation signals, not personal characterisations.
- Appropriate: "No qualifying activity for 21 days." Problematic: "Founder is disengaged."
- Appropriate: "Mission 7 has not been completed." Problematic: "Founder lacks motivation."
- Appropriate: "No evidence submission has been made." Problematic: "Founder is afraid of customer rejection."
Programme reporting describes observable programme state before inferring personal characteristics.
Where "at risk" indicators exist, they default to objective participation rules such as inactivity. Risk profiling derived from private founder work or AI inference requires separate review before it can exist at all.
11. Layer 4: Deliberately Shared Founder Outputs
Founders may share substantive work with programme personnel where the product supports it: a business plan, a pitch, a Mission output, an evidence submission or another specific deliverable.
Sharing must be specific, purposeful and transparent. You should be able to understand: what am I sharing? Who will receive it? Why am I sharing it? What happens after I share it?
Joining a programme, accepting an invitation or activating access never silently means "give the programme organisation unrestricted access to my private Founder Content". Programme participation and content sharing are separate concepts. Where a programme genuinely requires particular outputs, that requirement is clearly explained before you submit the work.
Sharing interfaces identify the recipient where practical: "Submit Business Plan to Acme Founder Programme" or "Share with Sarah Jones, Programme Mentor" rather than a bare "Share". This matters most where something shared with a mentor should not quietly reach a funder or assessor.
12. The Submitted Version Principle
When Founder Content is formally submitted to a programme, the programme receives the submitted version, not automatic access to every future private edit.
Submit Business Plan v3 to a programme and then privately write v4: version 4 remains private unless it is separately shared or submitted.
Submission creates access to the submitted state, not continuing surveillance of the founder's evolving private work.
Shared content (for collaboration or feedback, potentially revocable) is distinguished from formal submission (a programme deliverable the programme may legitimately need to retain). We do not promise deletion or revocation where formal programme requirements legitimately require retention.
13. Programme Roles and Least Privilege
Programme personnel do not all receive identical permissions. The architecture distinguishes roles such as administrator, facilitator, mentor, assessor and sponsor or funder, each receiving what their role reasonably requires.
A finance administrator handling programme licences does not automatically receive founder submissions. A mentor does not automatically receive programme-wide administrative information about every founder. A sponsor generally receives designed programme reporting rather than individual founder work.
Programme membership is not a universal permission role.
Programme administrators cannot widen access merely by changing dashboard settings. There is no configurable "allow us to see Founder Memory" or "show all AI conversations". Privacy boundaries are controlled by the platform, not delegated to programme customers.
14. Layer 5: Programme Outcomes
Programme Delivery legitimately requires outcome measurement: participation, activation, completion, progression, capability measures, milestones and agreed performance indicators.
Where individual-level identification is unnecessary, reporting uses aggregated or appropriately de-identified information.
"68% of programme participants completed customer validation" is different from "Alex has not validated their customer". Individual operational progress and programme-level outcome evaluation are distinguished, and any individual outcome data is defined as part of the visibility model rather than inferred from general access.
Zero→1 should be capable of demonstrating programme outcomes without exposing founders' private operating environments.
15. No Hidden Founder Scoring, No Silent Automated Decisions
Programme organisations do not automatically receive opaque AI-generated classifications such as a "Founder Potential Score", "Likelihood of Success", "Motivation Score" or "Commitment Score". This matters most where organisations might use such scores to allocate opportunities, funding or mentoring.
Founder Intelligence does not silently become an automated programme eligibility or assessment engine. Using Zero→1 information to determine funding, selection, awards, progression, certification or employment opportunities requires separate assessment before any such feature exists.
Programme access to information does not itself authorise automated decision-making based on that information.
16. Sponsors, Funders and Employers
A university, accelerator, local authority, government body, bank, employer, foundation or corporate sponsor may pay for programme delivery. That gives the organisation the rights expressly defined by the programme relationship. It does not give unrestricted rights over Founder Content, Founder Memory, Founder Intelligence conversations, private business plans, raw research or AI profiles.
Employer-sponsored programmes deserve particular caution: a founder may reasonably perceive significant consequences if private entrepreneurial thinking becomes visible to their employer. The visibility model applies in full even where an employer pays.
Employer sponsorship must not silently convert Zero→1 into an employee-monitoring tool.
17. Younger Founders
This Standard applies equally to founders aged 16 and 17. We do not create a separate programme architecture for younger founders; the company-wide architecture provides strong privacy for everyone.
For younger founders in particular: sharing defaults remain high privacy, programme visibility stays necessary and proportionate, recipients and purposes stay understandable, privacy-reducing nudges are not used, and AI-derived profiling receives heightened scrutiny.
The programme-joining experience explains relevant visibility in language appropriate to the audience.
18. What You Are Told, and When
Before or when you join a programme, you receive a concise explanation of what the programme can see, in the spirit of:
"Your programme can see that you've joined, your progress through the programme and whether required activities are complete. Your private answers, Founder Intelligence conversations and Founder Memory remain private unless you specifically share or submit something."
We will not promise a narrower visibility model than the product actually provides.
When you deliberately share or submit substantive work, the product explains it in context: "This will share the current version of your Business Plan with Acme Founder Programme for programme assessment."
Programme UX never pressures you to expose private work: no "share everything to get the most from your programme", no pre-selected sharing defaults where sharing is not necessary, and no penalty for keeping information private unless a specific item is genuinely required for a clearly defined programme activity.
19. Exports, Integrations and Notifications
Exports and integrations preserve the same visibility model. An API, CSV export, webhook or reporting integration does not provide information that the programme user could not legitimately access through the Zero→1 interface, and respects role, purpose, field-level visibility, founder sharing state and programme scope.
Integration does not create new data rights.
Notifications follow the same rules. "Alex completed Mission 6" is appropriate; "Alex completed Mission 6 and concluded their business has insufficient demand" is not, unless that substantive outcome was specifically intended for programme visibility.
20. Leaving a Programme, Keeping Your Journey
Leaving a programme does not transfer the founder's private operating environment to the programme organisation.
When you complete a programme, leave early or lose sponsored access, programme access ends or reduces according to the legitimate continuing purpose. Formal submissions and necessary programme records may remain where properly required; private Founder Memory and Founder Intelligence conversations remain outside ordinary programme access.
Where commercially and technically appropriate, you should be able to continue your Zero→1 journey after a sponsored programme without losing your private operating history merely because the sponsoring organisation stops paying.
The programme relationship belongs to the programme. The founder's operating journey belongs with the founder.
21. Inside Zero→1
Programme functionality does not change our private-by-default internal-access rule. Zero→1 personnel process information where legitimately required to operate, support, secure or lawfully administer the service. Technical ability does not create permission for unnecessary internal browsing of founder work.
For sensitive programme-visible content, the architecture can establish which programme roles have permission to access which categories, and access to higher-sensitivity shared content can be audited. Institutional access is not opaque where material founder information is involved.
22. Questions
Read this Standard alongside our Founder Intelligence Agency Standard, Founder Memory Governance Standard and Privacy Notice.
Questions or concerns: support@zeroto1.co.uk
Founder Progress Ltd
trading as Zero→1
Company number: 17333996