What this document covers.
Start with the key points, then use the contents menu to move through the complete public document.
- 01 · Standard
- Respectful, direct, and evidence-based collaboration.
- 02 · Security
- Least privilege and approved sharing channels.
- 03 · Escalation
- Concerns can be raised without retaliation.
Purpose and scope
The code applies across project conversations, delivery, and support.
These standards apply to SuperNetrix, clients, prospective clients, vetted independent specialists, partners, vendors, and anyone participating in a project channel, meeting, document, repository, review, or support interaction.
A signed project agreement may add more specific requirements. Where it sets a higher standard, the signed requirement should be followed.
Respect people
Professional disagreement is welcome; harassment and abuse are not.
Communicate professionally across calls, email, chat, tickets, documents, code review, and feedback sessions. Challenge ideas with reasons and evidence while respecting the person who raised them.
Harassment, discrimination, threats, stalking, bullying, retaliation, hate speech, deliberate intimidation, sexual misconduct, or abusive pressure is not acceptable.
Inclusive collaboration
Participation should not depend on identity, background, location, or communication style.
Make room for questions, different levels of domain knowledge, accessibility needs, time-zone constraints, and reasonable cultural or communication differences. Avoid exclusionary language and explain project-specific shorthand when it affects a decision.
Reasonable adjustments should be discussed early so the team can plan communication, review, and meeting formats that allow people to contribute effectively.
Make feedback useful
Good feedback is specific, timely, actionable, and connected to an outcome.
Describe the observed issue, affected user or workflow, desired outcome, and relevant evidence. Raise material concerns early enough for the team to respond without creating avoidable rework.
Avoid personal attacks, vague blame, public shaming, moving acceptance criteria without discussion, and manufactured urgency. Record important decisions where the delivery team can find them.
Represent the work honestly
Shipped, proposed, blocked, experimental, and unverified work must remain distinct.
Do not invent outcomes, conceal material risks, misstate contribution scope, or present private work as public proof. Status updates should distinguish confirmed facts from assumptions and recommendations.
Scope, dependencies, acceptance criteria, decision owners, and material changes should be made clear. When evidence is incomplete, say what is known and what still needs verification.
Client and participant responsibilities
Delivery depends on authorised access, timely decisions, and accurate inputs.
Participants should provide information and access they are authorised to share, identify material constraints, review decisions within agreed windows, and promptly report a change that affects scope, security, schedule, or compliance.
No participant should ask another person to bypass approvals, licensing terms, security controls, or applicable law. Business owners remain responsible for decisions that require their authority.
SuperNetrix responsibilities
The delivery team is expected to communicate directly and surface risk early.
SuperNetrix should describe its actual role, keep work close to the senior developers responsible for delivery, identify when a vetted specialist is involved, and avoid presenting independent specialists as permanent staff.
The team should explain material assumptions, trade-offs, blockers, and security concerns in language the relevant decision-maker can use. Reviews should focus on correctness, maintainability, performance, and user impact.
Protect access and information
Use approved channels, least privilege, and prompt incident reporting.
Credentials, source code, business records, customer information, private project material, and production access should be shared only through an approved secure channel and only with people who need them.
Use separate accounts where practical, enable suitable authentication controls, grant the minimum required access, and remove access when it is no longer needed. Suspected loss, disclosure, compromise, or unauthorised access should be reported promptly.
Use AI and automation responsibly
Automated systems should be lawful, reviewable, proportionate, and honest about limits.
Do not use project systems for deception, fraud, harmful impersonation, unlawful surveillance, unauthorised access, discriminatory decision-making, or another prohibited purpose.
Where automated output can create meaningful risk, the project should define suitable human review, testing, traceability, data boundaries, and fallback behaviour. AI-assisted work should not be represented as independently verified when it has not been reviewed.
Respect working boundaries
Channels, response expectations, and urgent work should be agreed rather than assumed.
Agree on primary communication channels, decision owners, review windows, meeting expectations, and escalation paths. Out-of-hours work, urgent changes, and materially expanded scope should be discussed explicitly.
Independent specialists who join an engagement should be introduced for their actual role and follow the same confidentiality, access, security, and conduct expectations.
Raise and resolve concerns
Concerns should be reviewed in good faith with proportionate action.
A concern can be raised with the relevant project lead or by emailing badri.supernetrix@gmail.com. Include enough factual context to understand the issue, but do not circulate sensitive material more widely than necessary.
SuperNetrix will aim to review concerns in good faith, limit unnecessary disclosure, and protect people from retaliation where reasonably possible. A response may include clarification, mediation, changed access, a written corrective action, removal from a project channel, or escalation under the project agreement.
Consequences and updates
Serious or repeated breaches can change or end the working relationship.
A serious or repeated breach may result in access removal, reassignment, a pause in work, or termination of participation or the engagement, subject to the applicable agreement and law. Immediate protective action may be taken where people, systems, or information are at risk.
This code may be updated as working practices, services, or legal requirements change. The document date identifies the latest public version.