Your best work is probably under an NDA, so nobody can see it. Nobody trusts CVs anymore, they are so fakeable. Redential reads your git history on your own machine and turns it into a profile of what you actually built. Never your code, and you see exactly what gets shared before it does. Then you defend it live, answering questions about your own work. The result: a credential recruiters can trust more than a CV. The CLI is free and open source.
No reviews yetBe the first to leave a review for Redential
This is amazing and looks similar to GitRoll project. However I have a question around AI assisted coding.
If I design the architecture of my project but rely on AI to generate specific functions without fully checking the internal logic, how does Redential determine whether I’m still the true author? In that case, what signals or defense questions does your system use to expose whether I actually understand the code I committed?
Quick difference from GitRoll: they look at public GitHub activity. We verify the work you can't show — and nothing counts without a live defense.
your question: we don't try to detect if AI wrote your code. that's fine. We check something else: do you understand what you shipped?
Good code alone doesn't earn you anything in Redential. You have to talk about it. The system asks you questions about your own repo, out loud: why did you build it this way, what happens if this part fails, what would you change. And it asks follow-ups based on your answers, so you can't memorize your way through.
In your case: you designed the architecture, so you can answer those questions, you'll do fine. Using AI to write functions is normal now, we're not against it. But if someone commits code they can't explain at all, they simply don't get the credential. Not called a cheater, they just haven't proven it yet.
Short version: we don't ask "did AI write this?" We ask "can you explain it?
@warengonzaga One more thing, since it's exactly what you're asking about: we're exploring a desktop app that asks you these questions right after you commit, while the work is fresh in your head, maybe by voice. All local, nothing leaves your machine until you choose to share. Would that feel useful to you, or annoying? Genuinely curious.
Report
Congrats on shipping. You said the git-history trust model is what you want people to try to break, I got curious about the dashboard side instead: once a team requests a defended profile, is that visible only to the team that requested it, or could a different team account pull up someone else's pending review before it goes public?
@vollos Thank you Chalermpon! So teams don't request defended profiles, and there's no pending review that later goes public. Devs defend their own work, and the only public thing is the dev's profile, which the dev owns and shares.
What teams get is an API: invite a candidate with a magic link, read the result of your own sessions only. Every API key belongs to one company and every read is filtered by it. Plus a private workspace to review your own candidates, with the defense audio and evidence behind each credential.
So no, another team can't pull up someone else's pending review. There's simply no shared pool to pull from.
Happy to hear what you think, and if you like to chat just schedule here
Report
@jpbelmo Where does that per-key filtering live, in the database itself, or in a check the API runs on every request?
Report
💡 Bright idea
What happens when you work in close enterprise git mostly and you are not allowed to install any unapproved apps.
@shahrukh_khan39 Tbh that's a real constraint and I won't tell you to sneak it past IT, that's not our vibe. Good news imo: this is the easiest kind of tool to get approved. Nothing installs (npx runs it once), scan makes zero network calls, and it's fully open source so your security team can literally read every line and run the privacy tests themselves. Btw a few folks have gotten it greenlit exactly that way, worth a quick ask to your sec team.
@tehreem_fatima5 The CLI is git-based, not GitHub-based: it reads local git history on your machine, so GitLab, Bitbucket and self-hosted repos already work. Only a small metadata summary you review ever leaves, no code, no file names, which is exactly the point for strict compliance setups. If you meant the sign-in or the connected-repo GitHub App, those are GitHub-first today with more planned. Which part did you have in mind?
Report
@jpbelmo Thanks for clarifying! I was mainly asking about the sign in and connected-repo integration side of things. Good to know more platform options are planned! Also, the metadata-only approach for local history gives great confidence for compliance.
Report
A really interesting approach to the problem. How (if at all) can you prove past work after leaving a company and losing access to its code? Also, can employers view shared profiles freely?
@mateuszkonik Timing matters tbh: the CLI reads local git history, so the move is to scan while you still legitimately have the repo on your machine (most devs scan before wrapping up a job).
Once you've lost all access there's nothing local to read, we can't conjure evidence from nothing. What you keep forever is the credential you built while you had it: the bundle lives on your profile, not in their repo.
And yes, sharing is the whole point: your profile is a link, anyone you send it to can open it, no account needed on their side.
Actually you just gave me an idea: I opened an issue for this ("how do you preserve evidence before losing access?") and see what the community comes up with. That's how our best improvements happened so far.
The proof happens on the dev's own machine: the open-source CLI reads the git history right where it lives and turns it into metadata (skills, activity, time spans, never code). Then they defend that work live, answering questions about their own decisions. So the claim gets tested without the repo ever going anywhere.
Btw if you ever feel like helping us harden the evidence, the CLI is open source, happy to have you there: github.com/Redential/redential-cli
Report
Dev credential based on what you actually built is better signal than certifications tbh. GitHub activity shows some of this but not the full story. How do you verify the contribution is genuine?
@abdurrahman_fakhrul Two paths today: the open-source CLI (for NDA work you can't show) and the GitHub App for repos you can connect. The App gives stronger verification because we can read the actual code. The CLI earns a lower, clearly labeled tier because local evidence is forgeable by nature, and that's exactly why it's open source: so people can red-team it, and we actively invite that in the repo.
The genuine check is the live defense: video and audio, recorded on your profile. Our AI generates questions from your real history (possible bugs, how you'd solve X, why you made this decision) and matches your answers against your commits. With a connected repo that matching is strong. With the CLI it's harder, which is why it stays the lower tier and why we harden it in public.
Before any of that, the basics: only commits YOU authored count, the emails you claim get checked against your verified addresses, signed commits can't be backdated without your key, and replayed histories leave a date signature the bundle ships.
Happy to have you as a contributor in our open source repo
This is amazing and looks similar to GitRoll project. However I have a question around AI assisted coding.
If I design the architecture of my project but rely on AI to generate specific functions without fully checking the internal logic, how does Redential determine whether I’m still the true author? In that case, what signals or defense questions does your system use to expose whether I actually understand the code I committed?
Redential
@warengonzaga thanks!!
Quick difference from GitRoll: they look at public GitHub activity. We verify the work you can't show — and nothing counts without a live defense.
your question: we don't try to detect if AI wrote your code. that's fine. We check something else: do you understand what you shipped?
Good code alone doesn't earn you anything in Redential. You have to talk about it. The system asks you questions about your own repo, out loud: why did you build it this way, what happens if this part fails, what would you change. And it asks follow-ups based on your answers, so you can't memorize your way through.
In your case: you designed the architecture, so you can answer those questions, you'll do fine. Using AI to write functions is normal now, we're not against it. But if someone commits code they can't explain at all, they simply don't get the credential. Not called a cheater, they just haven't proven it yet.
Short version: we don't ask "did AI write this?" We ask "can you explain it?
Redential
@warengonzaga One more thing, since it's exactly what you're asking about: we're exploring a desktop app that asks you these questions right after you commit, while the work is fresh in your head, maybe by voice. All local, nothing leaves your machine until you choose to share. Would that feel useful to you, or annoying? Genuinely curious.
Congrats on shipping. You said the git-history trust model is what you want people to try to break, I got curious about the dashboard side instead: once a team requests a defended profile, is that visible only to the team that requested it, or could a different team account pull up someone else's pending review before it goes public?
Redential
@vollos Thank you Chalermpon! So teams don't request defended profiles, and there's no pending review that later goes public. Devs defend their own work, and the only public thing is the dev's profile, which the dev owns and shares.
What teams get is an API: invite a candidate with a magic link, read the result of your own sessions only. Every API key belongs to one company and every read is filtered by it. Plus a private workspace to review your own candidates, with the defense audio and evidence behind each credential.
So no, another team can't pull up someone else's pending review. There's simply no shared pool to pull from.
Happy to hear what you think, and if you like to chat just schedule here
@jpbelmo Where does that per-key filtering live, in the database itself, or in a check the API runs on every request?
What happens when you work in close enterprise git mostly and you are not allowed to install any unapproved apps.
Redential
@shahrukh_khan39 Tbh that's a real constraint and I won't tell you to sneak it past IT, that's not our vibe. Good news imo: this is the easiest kind of tool to get approved. Nothing installs (npx runs it once), scan makes zero network calls, and it's fully open source so your security team can literally read every line and run the privacy tests themselves. Btw a few folks have gotten it greenlit exactly that way, worth a quick ask to your sec team.
You can check our open source repo here.
Redential
@tehreem_fatima5 The CLI is git-based, not GitHub-based: it reads local git history on your machine, so GitLab, Bitbucket and self-hosted repos already work. Only a small metadata summary you review ever leaves, no code, no file names, which is exactly the point for strict compliance setups. If you meant the sign-in or the connected-repo GitHub App, those are GitHub-first today with more planned. Which part did you have in mind?
A really interesting approach to the problem. How (if at all) can you prove past work after leaving a company and losing access to its code? Also, can employers view shared profiles freely?
Redential
@mateuszkonik Timing matters tbh: the CLI reads local git history, so the move is to scan while you still legitimately have the repo on your machine (most devs scan before wrapping up a job).
Once you've lost all access there's nothing local to read, we can't conjure evidence from nothing. What you keep forever is the credential you built while you had it: the bundle lives on your profile, not in their repo.
And yes, sharing is the whole point: your profile is a link, anyone you send it to can open it, no account needed on their side.
Actually you just gave me an idea: I opened an issue for this ("how do you preserve evidence before losing access?") and see what the community comes up with. That's how our best improvements happened so far.
Trovio For Brands
Congrats on the launch!!
Verification is the interesting part here. How do you prove someone actually built what they claim without access to private repos?
Redential
The proof happens on the dev's own machine: the open-source CLI reads the git history right where it lives and turns it into metadata (skills, activity, time spans, never code). Then they defend that work live, answering questions about their own decisions. So the claim gets tested without the repo ever going anywhere.
Btw if you ever feel like helping us harden the evidence, the CLI is open source, happy to have you there: github.com/Redential/redential-cli
Dev credential based on what you actually built is better signal than certifications tbh. GitHub activity shows some of this but not the full story. How do you verify the contribution is genuine?
Redential
@abdurrahman_fakhrul Two paths today: the open-source CLI (for NDA work you can't show) and the GitHub App for repos you can connect. The App gives stronger verification because we can read the actual code. The CLI earns a lower, clearly labeled tier because local evidence is forgeable by nature, and that's exactly why it's open source: so people can red-team it, and we actively invite that in the repo.
The genuine check is the live defense: video and audio, recorded on your profile. Our AI generates questions from your real history (possible bugs, how you'd solve X, why you made this decision) and matches your answers against your commits. With a connected repo that matching is strong. With the CLI it's harder, which is why it stays the lower tier and why we harden it in public.
Before any of that, the basics: only commits YOU authored count, the emails you claim get checked against your verified addresses, signed commits can't be backdated without your key, and replayed histories leave a date signature the bundle ships.
Happy to have you as a contributor in our open source repo