01
Researchers & universities
Joint investigations, technical validation, prototypes, reproducible evidence, or implementation work that helps a research question meet operational reality.
Collaboration / working together
question → scope → pilot → evaluate → continue / share
ROCSI is most useful where research and engineering need to meet real operating conditions—not where the answer has already been reduced to a generic delivery brief.
Bring a real constraint into the work.
Useful collaboration starts with something concrete: a research question, deployment context, dataset, integration requirement, failure case, technical capability, or practical support that can make an experiment more inspectable and a system more resilient.
01 / Who ROCSI is open to working with
Different contexts. Shared need for evidence.
The useful common denominator is not sector or organization size. It is a problem that benefits from investigation, technical experimentation, and explicit constraints.
02
Public institutions
Public-interest problems involving digital services, information flows, interoperability, resilience, participation, or inspectable infrastructure.
03
NGOs & civic organizations
Civic and societal problems where technology can support participation, access to information, evidence, or more resilient community systems.
04
Companies & technical teams
Applied R&D, integrations, pilots, validation work, or system questions that need more than routine implementation.
05
Technical contributors
Open-source review, testing, documentation, implementation, datasets, specialist expertise, or focused contributions to public technical work.
06
Programme & ecosystem partners
Programmes, funders, networks, and enabling organizations where the fit is grounded in a concrete research or deployment objective rather than affiliation for its own sake.
02 / Ways of working together
Collaboration should produce something inspectable.
The format depends on the question. A collaboration may stop after a useful investigation or continue into a prototype, pilot, integration, or maintained system.
01
Joint research
Frame a question together, identify assumptions and evidence, and document what the investigation changes.
02
Technical prototyping
Turn an uncertain idea into a working artifact, interface, data flow, or simulation that can expose real constraints.
03
Pilot deployments
Test a bounded system in a realistic context before treating experimental results as production guarantees.
04
Integrations
Connect systems where interoperability, maintainability, data boundaries, or operational visibility are part of the problem.
05
Data & evaluation
Work with datasets, observations, validation methods, benchmarks, or evidence that can improve an experiment or challenge an assumption.
06
Workshops & knowledge exchange
Focused sessions around methods, architecture, emerging technologies, civic technology, resilience, or practical AI use where a concrete outcome is defined.
07
Open-source contribution
Review code, test edge cases, improve documentation, contribute fixes, or extend open tools and integrations.
08
Commissioned applied R&D
Scoped research and engineering work where uncertainty, experimentation, and technical evidence are central—not generic software outsourcing.
03 / What ROCSI brings
Research questions carried into working systems.
ROCSI contributes an applied-R&D operating model that keeps evidence, implementation decisions, and system boundaries visible throughout the work.
01
Research framing
Turn a broad concern into questions, assumptions, constraints, and evidence that can actually be tested.
02
Rapid experimentation
Make uncertainty tangible through prototypes, simulations, interfaces, and technical proofs of concept.
03
Technical implementation
Carry what survives testing into deliberate engineering while keeping maintainability and operational context visible.
04
Systems thinking
Keep relationships among people, information, technology, institutions, and infrastructure in view when they affect resilience.
05
Inspectable technical trails
Document decisions, evidence, limits, and releases where doing so improves inspection, contribution, or reuse.
06
Claims proportional to evidence
Separate observed results from security, safety, production, or institutional guarantees that have not been established.
04 / A good fit
Not every software brief needs an R&D collaboration.
A useful fit usually contains uncertainty worth resolving and enough real context to test whether an idea survives contact with operating conditions.
Good-fit signals
- 01There is a real technical, societal, or research question rather than only a predetermined feature list.
- 02The work benefits from experimentation, validation, or evidence before large implementation commitments are made.
- 03Constraints, users, data, infrastructure, deployment context, or failure conditions can be made explicit.
- 04The question connects meaningfully with one or more ROCSI Research areas or Current Work systems.
- 05The outcome can leave a useful technical, research, or operational trail even if the first hypothesis does not survive.
What this is not
- 01A generic web-development or design agency engagement with research language added around it.
- 02Staff augmentation or undifferentiated software outsourcing where the problem and implementation path are already fixed.
- 03A promise of partnership, funding, production readiness, security certification, or a predetermined result before evidence exists.
05 / Engagement model
A staged path from uncertainty to evidence.
The sequence keeps commitments proportional to what is known. A useful collaboration can stop at any stage if the evidence says it should.
01
Explore
Understand the problem.
Clarify the question, context, constraints, affected systems, and what would count as a useful outcome.
02
Scope
Define a testable boundary.
Decide whether the fit is real and shape a feasible investigation, prototype, pilot, integration, or project boundary.
03
Pilot / build
Make the hypothesis operational.
Run the investigation or build enough of the system to expose technical, organizational, and deployment constraints.
04
Evaluate
Inspect what the evidence changed.
Review results, failures, limitations, trade-offs, and what can or cannot be claimed after the work.
05
Continue / share
Choose the next responsible step.
Extend, deploy, document, publish, contribute upstream, maintain, or stop based on what was learned.
06 / Where collaboration can start
Start from work that already has context.
Current Work provides concrete systems around which testing, deployment context, technical expertise, evidence, integrations, or critical review can become useful immediately. Research and Workbench provide the broader questions and technical trail.
Current Work / 03
Civic Technology
Platforma Civică
A beta/demo civic-tech platform for participation, public visibility, and the relationship between citizens and institutions. It brings together public announcements and consultations, civic reports and complaints, polls and referendums, an institution map, and assisted tools for explaining documents and preparing official requests.
Explore project →Open-source integration
Connector for NMKR
An open-source WordPress connector that synchronizes Cardano and Solana project and token data from NMKR Studio through the NMKR API, stores it locally, and exposes it through responsive shortcodes.
Explore project →Trustworthy Infrastructure
Telemetry Attestation Gateway
Privacy-preserving telemetry attestation research using zero-knowledge proofs (ZKP) to prove narrowly scoped properties of vehicle telemetry without exposing the underlying sensitive data. The documented work is simulation-first and vehicle/drone-oriented, including autonomous-vehicle contexts, while explicitly excluding flight control, command authorization, and autonomous decision execution.
Explore project →07 / Funding & partnerships
Support applied R&D around a concrete objective.
ROCSI is open to conversations with organizations and individuals that can support or accelerate applied research and development through funding, access to real testing contexts, specialist expertise, or strategic partnership.
The useful starting point is a clearly bounded problem, research objective, or project. Funding is not presented as an end in itself, and it does not imply automatic acceptance of an engagement or a predetermined outcome.
- 01Research grants and R&D funding.
- 02Sponsorship of clearly scoped R&D activities or work packages.
- 03Strategic partnerships, pilots, and access to real deployment contexts.
- 04Investment discussions where there is a genuine fit between project stage, objectives, and form of capital.
08 / Start a conversation
Bring the constraint into the first conversation.
A useful first conversation can be short and focused. Bring the problem or question, the context in which it exists, important constraints, and why you think ROCSI may be relevant.
If there is already a dataset, repository, architecture note, public document, deployment environment, or failure case that makes the problem concrete, have it ready where appropriate.
Scheduling a first conversation does not imply a response-time guarantee, project acceptance, funding, or delivery commitment.